- 武田大輝
- 約 3,400 文字
- 40,300 View
目次
こんにちは。TIG DXユニット 1の武田です。
はじめに
みなさんSwagger使ってますか?
当社でもREST APIを構築するに当たってSwaggerを導入する機会が増えています。本記事ではSwaggerを導入するに当たって、合わせて利用して便利だったツールを紹介したいと思います。
そもそもSwaggerとは?
Swaggerは、OpenAPI仕様(以下OAS)と言われる、REST APIを定義するための標準仕様にもとづいて構築された一連のオープンソースツールです。REST APIの設計、構築、文書化、および使用に役立つ機能を提供します。
提供されている主なツールは次のようなものがあります。
| Name | Description |
|---|---|
| Swagger Editor | OASに則ったAPI仕様を書くためのエディタ |
| Swagger UI | OASに則ったAPI仕様からドキュメントを生成するツール |
| Swagger Codegen | OASに則ったAPI仕様からコードを生成するツール |
サードパーティ製のツール
本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。
エコシステムが成熟しているのもSwaggerを利用するメリットの1つですね。
https://openapi.tools/
冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。
Stoplight Studio
1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。
今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。
Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速にAPI仕様を記述できます。
主な特徴
主な特徴としては次のようなものが挙げられます。
- 無料
- Web、バイナリ(Windows、Mac、Linux)として配布
- OpenAPI v2 & v3に対応
- Git連携
- Prismと呼ばれるモックサーバ(後述)を統合
- ドキュメントへの変換に対応
- リアルタイムでLintエラーを表示
筆者はもうこのエディタなしではSwaggerを書けない体になりました。Webから簡単に試すことができるので実際に使ってみるのが一番だと思います。
https://stoplight.io/p/studio/gh/stoplightio/studio
Prism
https://stoplight.io/open-source/prism
2つ目のツールは「Prism」というStoplight Studioと同じくStoplight社が提供するOSSのモックサーバです。
コマンドラインからOAS定義を読み込むことで簡単にAPIのモックサーバが起動できます。例えばサーバ(API)側ができていない状態で、クライアント側の開発を進めるケースなどでは非常に有用ですね。
主な特徴
主な特徴としては次のようなものが挙げられます。
- OSS
- OpenAPI v2 & v3に対応
- Nodeモジュール、バイナリ(Windows、Mac、Linux)、Dockerイメージとして配布
- ダイナミックレスポンス対応
- リクエストのバリデーション対応
- CORS対応
apisproutなど他のモックサーバも多数存在しますが、ランタイムなしで利用できる点やダイナミックレスポンス、CORS対応等、地味に嬉しい機能があり、お気に入りです。
使ってみた
今回はDockerイメージ利用してみます。 サンプルのOAS定義としてSwagger Petstoreを利用します。定義内容はこちら。
まずはヘルプコマンド
利用可能なオプションは次のとおりとなります。
docker run stoplight/prism:3 mock -h |
サーバ起動
引数にOAS定義を指定して prism mock コマンドを実行するとモックサーバが立ち上がります。
docker run --rm -it -p 4010:4010 stoplight/prism:3 mock -h 0.0.0.0 https://petstore.swagger.io/v2/swagger.json |
ローカルから繋いでみます。 定義した通りのレスポンスが返却されていますね。
curl -s -D /dev/stderr -X GET -H "Accept:application/json" http://localhost:4010/pet/0001 | json_pp |
ダイナミックレスポンス
モックサーバ起動時に-dオプションを付与すると、OAS定義にもとづいてリクエストのたびにレスポンスが動的に作成されます。
docker run --rm -it -p 4010:4010 stoplight/prism:3 mock -h 0.0.0.0 -d https://petstore.swagger.io/v2/swagger.json |
1回目
curl -s -D /dev/stderr -X GET -H "Accept:application/json" http://localhost:4010/pet/0001?hoge=dow | json_pp |
2回目
curl -s -D /dev/stderr -X GET -H "Accept:application/json" http://localhost:4010/pet/0001?hoge=dow | json_pp |
バリデーション
リクエストボディを指定せずに POST: http://0.0.0.0:4010/petを投げてみるとエラーが返却されます。
このようにOAS定義にもとづいてクエリパラメータやリクエストボディのバリデーションを行ってくれます。
返却されるエラーの詳細は公式のドキュメントを参考にしてみてください。
curl -s -D /dev/stderr -X POST -H "Accept:application/json" http://localhost:4010/pet | json_pp |
CORS
Prismはデフォルトで、全てのメソッドと全てのオリジンを許可するため、全てのプリフライトリクエストを204でハンドリングします。
ローカルで(Webpack Dev Server等を利用して)Web開発をしているときに、プロキシを設定したりしなくて済むのは、嬉しいですね。
Dredd
最後に紹介するツールは「Dredd」というOAS定義と実際のAPIサーバを検証するコマンドラインベースのテストツールになります。
要はAPIのレスポンスがOAS定義通りだよね? というのを確認してくれるツールです。もともとはAPI Blueprintに対応していたツールですが、OpenAPIにも対応がなされました。
主な特徴
主な特徴としては次のようなものが挙げられます。
- OpenAPI v2 & v3に対応(ただしv3はExperimental)
- Nodeモジュール、Dockerイメージとして配布
- テスト時の前処理、後処理をさまざまな言語(Go, Node.js, Perl, Python, Ruby, etc…)で定義可能
使ってみた
テスト対象のAPIサーバはlocalhost:4010で動いている前提とします。
テスト仕様書となるOAS定義として今回もSwagger Petstoreを利用したいところですが、そのまま利用するには色々と問題があるみたいなので、Petstoreを修正した簡易版のOAS定義を作成し利用します。
IDをキーにペットを取得するAPI、更新するAPIの2APIを定義しています。
GET : /pet/{petId}POST: /pet/${petId}
swagger: "2.0" |
正常系
OAS定義と実際のAPIサーバのホストを引き数にdredd コマンドを実行すると2本のAPIのリクエストが投げられ、レスポンスが検証されます。
dredd swagger.yaml localhost:4010 -h "Accept:application/json" |
異常系
テスト対象のAPIサーバのロジックを修正し、OAS定義と異なるレスポンスを返却するようにしてみましょう。
今回は、GETレスポンスのstatusがavailable pending soldのいずれのenum値にも当てはまらない値(hoge)を返します。
fail: body: At '/status' No enum match for: "hoge"とログが出力され、期待通りテストが失敗していますね。
dredd swagger.yml localhost:4010 -h "Accept:application/json" |
このようにDreddを利用すれば、実際のAPIサーバがOAS定義に則ったレスポンスを返却しているかを検証できます。
さらに今回は触れませんでしたが、テストの前処理、後処理等でDBをクリーンアップしたり、テストデータを投入したりすれば、E2EのCIを実現できます。
もともとAPI Blueprint用のツールだったこともあり、OpenAPIの扱いで筋力が必要なシーンが少なからずありますが、このあたりの泥臭い話は別途記載できればと思います。
各種ツールの統合
標準的な設計・開発プロセスにご紹介したツールを統合すると次のような形になります。
みなさんもクライアントサイドとサーバサイドの結合テストにおいてインターフェースの齟齬による苦労をした経験はあるかと思います。
OAS定義を一元管理し、prismやDreddを効果的に利用することでこのようなコストを大幅に削減でき、品質を強化できます。
ご参考になれば幸いです。
このスキーマファースト開発のためのOpenAPI(Swagger)設計規約 記事もおすすめです。
- 1.Technology Innovation Groupの略で、フューチャーの中でも特にIT技術に特化した部隊です。その中でもDXチームは特にデジタルトランスフォーメーションに関わる仕事を推進していくチームです。 ↩