OpenAPIのファイルを分割している話
株式会社IVRy （アイブリー）のエンジニアの kinashi です。 IVRy では設定画面の Web アプリケーションは Ruby on Rails と Next.js で構成されています。 I/F 定義には OpenAPI を使っていて、各リポジトリから Git のサブモジュールで参照し、スキーマ駆動で開発しています。 2022年の夏にリプレイスをし、今の構成になってから早1年半、1ファイルで管理していた OpenAPI の定義も1.3万行ほどになりました。 リプレイスに関する記事はこちら 定義の追加や編集、レビューなどが辛くなっているので、1ファイルでの定義から脱却したい！ ということで、徐々に分割を行っている最中です。 なぜ今までファイル分割していなかったのか スキーマ定義通りの実装にするため、バックエンドでは committee-rails 、フロントエンドでは openapi
OpenAPI Generatorに適したOpenAPIの書き方 - ZOZO TECH BLOG
はじめに こんにちは！ WEARバックエンドブロックの高久です。 WEARではOpenAPI（Swagger）を使って、アプリやWebのクライアントが利用するAPIを定義しています。そして先日、開発効率化のためにOpenAPI GeneratorでOpenAPIからAPIクライアントコードを自動生成、活用できるように整備をしました。その中でOpenAPI Generatorに適したOpenAPIの書き方のポイントがいくつかあったので、内容を紹介していきます。 想定読者 OpenAPIを現在利用している、またはこれから利用する予定の方 OpenAPI Generatorを利用したコード自動生成を検討している方 背景 当初WEARではAPIクライアントコードはOpenAPIでのAPI定義を基に各クライアントが手動で実装していました。しかし手動で実装すると初期の実装コストや変更時の追従コストがか
OpenAPI仕様と公開されているスキーマファイル群の同期が取れていない件 - Qiita
"paths": { "$comment": "https://spec.openapis.org/oas/v3.1.0#paths-object", "type": "object", "patternProperties": { "^/": { "$ref": "#/$defs/path-item" } }, "$ref": "#/$defs/specification-extensions", "unevaluatedProperties": false }, "#/$defs/path-item" となっている箇所は "#/$defs/path-item-or-reference" であるべきなのではないか、という疑念だ。 そこで、OpenAPI コミュニティの Slack に参加して質問したところ、「その問題は PR 3355: Fix 3.1 Path Item schema
OpenAPI Generatorを使って生成するSpring Web MVCのソースコードに、独自にバリデーションを追加したい - CLOVER🍀
これは、なにをしたくて書いたもの？ OpenAPIを使ってREST APIを定義した時に、requiredや文字列長、範囲についての記述をしておくと、OpenAPI Generatorを使って 自動生成した時にある程度バリデーションの定義も生成してくれます。 OpenAPI Specification v3.0.3 / Specification / Schema / Data Types OpenAPI Specification v3.0.3 / Specification / Schema / Schema Object / Properties とはいえ、そのままでは生成されるバリデーションには限界があるので、自分でバリデーション定義を追加したい場合は どうしたらよいのかな？と思って調べてみました。 方法は？ 調べてみると、ざっくり次の2つの方法がありそうです。 OpenAPIの拡
OpenAPI 3.0.3 と 3.1.0 どっち使う？ | フューチャー技術ブログ
Swaggerを使う事になり OpenAPIを触ってみると 3.0.3 と 3.1.0 が存在します。どちらを使うべきが悩んだので調べて整理してみました。 3.0.3 から 3.1.0 への変更点は過去のポストを参照ください。 参考: Open API Specification 3.1と気になる仕様策定 結論Amazon API Gateway を使い、OpenAPIで定義されたAPI仕様書のインポート機能 を利用する場合は 3.0系（ 3.0.3）一択です。理由は単純に執筆時点では Amazon API Gateway が 3.1系 に対応してないからです。 また、VSCodeの拡張機能の中には 3.0.3 に対応しているものの 3.1.0 には未対応のものも多いようです（決して 3.1.0 で書けないわけではないありません） https://github.com/42Crunch/v
[Power Automate] カスタムコネクタをOpenAPI Specification (OAS) で学ぶ - Qiita
（この記事は、2022/10/01に行われた「気ままに勉強会 #34」で使用したスライドを元にしています） 注意事項 この記事は、実用性を目指しておりません。何かを解決できる話ではありません。 この記事は、私が付け焼き刃で仕入れた知識を披露しているだけで、多くの誤りや、個人の見解が含まれていると思われます。 この記事の内容を鵜呑みにしないでください。 APIはいろいろなものをつなぐ APIとは Application Programming Interface 「ソフトウエア」のための「インターフェイス」 以下のもので構成されています。 「仕様」(Specification) 「インターフェイス」(Interface) Web APIはHTTP(HTTPS)を使う Web APIとはHTTP(HTTPS)プロトコルを使って 「リモート」 でソフトウエア／サービスを操作するためのインターフェ
![[Power Automate] カスタムコネクタをOpenAPI Specification (OAS) で学ぶ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ddb06fac456cfa61397140eda6860979f17707d8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUG93ZXIlMjBBdXRvbWF0ZSU1RCUyMCVFMyU4MiVBQiVFMyU4MiVCOSVFMyU4MiVCRiVFMyU4MyVBMCVFMyU4MiVCMyVFMyU4MyU4RCVFMyU4MiVBRiVFMyU4MiVCRiVFMyU4MiU5Mk9wZW5BUEklMjBTcGVjaWZpY2F0aW9uJTIwJTI4T0FTJTI5JTIwJUUzJTgxJUE3JUU1JUFEJUE2JUUzJTgxJUI2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0yZGJjZDc2NmU1ZjVjMzBlYmY3ZWQxZWE0ZDA1ZGFiZA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzcHVtb25pJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1lNWVkNzkxN2YxMTUzYTAyMDdmYzAwNmY1ZTY0YzNjNg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D1c17c2c4eec8471895c942b789876222)
ReadableなOpenAPI定義ファイルを書く - ドワンゴ教育サービス開発者ブログ
一行要約 はじめに Readable OpenAPIとは? 既存ルールの不満点 不満点1: 標準仕様外の分割を行っている 不満点2: ディレクトリ階層が深い 不満点3: 1つのAPI定義を参照する際にたくさんのファイルを参照する必要がある 不満点4: コンポーネントスキーマの同一性が不明瞭 新ルールで工夫した点 工夫1: operationIdと対応したパス定義のファイル名を採用し、フラットなディレクトリ構造を実現した 工夫2: パス定義ファイルに含まれる情報量を増やした 工夫3: 再利用性を重視したcomponent定義 できなかったこと、やらなかったこと、やりたいこと 定義ファイルのhttpメソッドごとの分割ができなかった ルートの定義ファイルにcomponentディレクティブを置かなかった exampleの定義は余力があればやりたい おわりに We are hiring! 脚注 一行
OpenAPI Generator で API Client と型を自動生成した話 - BASEプロダクトチームブログ
フロントエンドエンジニアの @rry です。 自分は BASE の Sales Promotion というチームで主に新規機能開発を行っています。このチームでは主にオーナーさんの使う管理画面に新しく機能追加をしています。 そこで、管理画面で使っている API Client と型を、OpenAPI Generator を使って自動生成するようにしてみたのでそのお話を書きたいと思います。 そもそも OpenAPI とは？ https://www.openapis.org/ OpenAPI とは、RESTful Web サービスを記述、生成、使用、および視覚化するための仕様です。 ※ 以前は OpenAPI ではなく仕様自体も Swagger と呼ばれていましたが、現在は仕様自体については OpneAPI と呼ばれており、Swagger というのは OpenAPI を使ったツール群のことをさすよ
OpenAPIを使ってAPIドキュメントとモックサーバーを良い感じにした話
2021年6月2日に行われたSendai Frontend Meetup #6で使用したスライドです。 GitHub サンプルコード https://github.com/KanDai/openapi-sample ReDocで生成されたドキュメント https://kandai.github.io/openapi-sample/ About Swagger Specification https://swagger.io/docs/specification/about/ Swagger Editor https://editor.swagger.io/ Stoplight Studio https://stoplight.io/api-design/ Swagger UI https://petstore.swagger.io/ Redoc https://github.com/Red
Swaggerを使ったAPIドキュメントの作成と、バックエンドとフロントエンド間の連携
こんにちは。LINE Growth Technology福岡開発室でサーバーサイドエンジニアをしている中村です。 この記事では担当していたプロジェクトで実施した、Swaggerを使ったAPIドキュメントの作成と、BE（バックエンド）とFE（フロントエンド）間の連携について紹介します。 プロジェクトの説明 はじめに、今回LINE Growth Technology福岡開発室（以下「GT」）がシステムの設計開発を担当した、LINE公式アカウント審査ツールのプロジェクトについて説明します。 LINE公式アカウント審査ツールとは、LINE公式アカウントで認証済アカウントが申請された際に、申請内容が適切であるか審査するシステムです。 このシステムは、LINE公式アカウントが利用されている各国に存在する審査パートというチーム（以下「審査チーム」）によって利用され、日本以外の国家も含め、一日あたり平均約
Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita
はじめに 私の職場では、WebAPIの仕様書をWordで書く習慣があったのですが、2018年頃にSwaggerで書くように切り替わったので、そのように変化した経緯を書きます。 何かの参考になれば幸いです。 ちなみに、こちらの記事と同じ職場です。 Wordな職場にMarkdownを定着させるためにやった４つのこと Swaggerとは？ Swaggerとは、REST APIの仕様を定義するためのフォーマットです。その周辺技術も含めて、Swaggerと呼ばれます。以下の記事が非常に参考になりますので、詳細を知りたい方はご参照ください。 Swaggerの概要をまとめてみた。 Swagger 導入失敗 2016年頃のある日、上司から「世の中にはSwaggerというものがあるらしい。調べてもらえる？」と指示されました。 調べてみたところ、Swaggerがあれば、WebAPIのドキュメントサイトも作れる
本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ
サードパーティ製のツール本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの1つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速
初めてのgRPC / Starting gRPC
JJUG CCC 2019 Springでの登壇資料です
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク RESTful APIの仕様を基に、APIクライアント用SDK、APIクライアントのテスト用にAPIサーバのように振る舞ってくれるスタブサーバ、Webサーバのコンフィグレーション、ドキュメントなどを自動生成してくれる「OpenAPI Generator」がオープンソースとして公開されました。 RESTful API仕様の記述フォーマットは、2015年にマイクロソフトやGoogle、IBMらが立ち上げた「Open API Initiative」が提唱する「OpenAPI Specification」が事実上の業界標準となっており、OpenAPI GeneratorもこのOpenAPI Specificationを基に開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iOS ライブラリをセルフサービスで生成する仕組み
Goで社内向け管理画面を楽に作る方法
まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜
GitHub - cam-inc/viron: OAS-driven Frontend-NoCode Administration Console