![[AWS] Amazon API GatewayでAPI Mockサーバー [作成とGETまで]](https://devio2023-media.developers.io/wp-content/uploads/2015/07/api_gateway.png)
[AWS] Amazon API GatewayでAPI Mockサーバー [作成とGETまで]
こんにちは。小室です。札幌市はここ数日ようやくまとまった雪が降ってます。 *1
今回はAmazon API Gatewayを利用したAPI Mockサーバーの簡単な作成手順を紹介します。
Amazon API Gateway
Amazon API Gatewayは、APIを簡単に作成することができます。API Gatewayの機能の一つである Mock Integration を利用することで、APIのMockサーバーを簡単に作成できます。
モバイルアプリ開発においては、よくAPIサーバーと同時並行で開発が行われるため、Mockサーバーを構築することがあるかと思います。Mockサーバーから本番サーバーへの切り替えなど、各開発者が苦労して色々と苦労しているかと思います。
Amazon API Gatewayを利用すると、どうやらMockと本番サーバーへの切り替えがコンソール上で簡単にできそうです。なかなか興味深い機能だったので、モバイルアプリケーション用の簡単なAPI Mockサーバーを作成してみます。これを使いこなすとモバイルアプリとAPIサーバーを同時並行で開発する際の強力なツールになるかもしれません（と期待して）
Mock APIを作成する
Amazon API GatewayでAPIを作成します。コンソールからAmazon API Gatewayを選択します。
リージョンは今のところ米国東部（バージニア北部）、米国西部（オレゴン）、EU（アイルランド）、アジア・パシフィック（東京） がサポートされています。
APIを作成
Create API を押すと新たにAPIを作成できます。まずは、APIの名称を決定します。今回は「Sample API」という名称のAPIを作成します。Descriptionは必須ではないので、適当に空でも問題ありません。
APIの作成が完了すると、以下のコンソール画面へ遷移します。Resourceの作成やMethodの作成を行います。
Resourceの作成
APIのパスの階層はResourceとして扱います。今回と次回で以下の2つのAPIを作成してみます。
- GET http://hogehoge.com/users : ユーザー情報一覧の取得
- GET http://hogehoge.com/users/{id} : ユーザーIDを指定してユーザー情報を取得
今回は1を。
まず users というリソースを作成します。 Create Resource を選択します。
Resource Name はリソースの名称を記載します。「users」をこちらに記載します。
Resource Path はResource Nameを記載すると自動的に作成されます。こちらは基本的にResource Nameと同じものが自動的に補完されますが、特に同じにする必要はありません。実際にAPIでPathとして指定するのは、こちらのResource Pathになります。
今回はResouce Nameと同じ「users」としています。
Create Resource をクリックするとResourceが作成されます。
users というResource Pathが作成されました。
Methodの作成（GET）
続いてMethodを作成します。コンソール左側のペインで /users を選択します。右のペインの Create Method をクリックします。するとResource Path以下に選択肢が現れます。
今回は、/users に対して GET を定義するので、選択肢から「GET」を選択します。
チェックマークをクリックすると、Methodの設定画面へ遷移します。
ここではAPI Gatewayで受けたGETリクエストをキッカケに、どんな処理をキックするかが設定できるようです。選択肢は以下の通りです。
| 機能 | 概要 |
|---|---|
| Lambda Function | API Gatewayで受けたリクエストから指定したLambdaを起動させます。 |
| HTTP Proxy | API Gatewayで受けたリクエストを別のHTTPサーバーへリクエストをリダイレクトします。 |
| Mock Integration | API Gatewayで受けたリクエストを受け、Mockレスポンスを返します。 |
| AWS Service Proxy | AWSのサービスを起動できるようです（まだ使ったことない） |
今回はMockサーバーを作成するのでMock Integration を選択します。「Save」ボタンをクリックします。
こちらが /users の GET メソッドの動作を定義する設定画面（Method Execution）になります。このコンソールからTest、リクエストのMapping、レスポンスのMappingなどを行うことができます。
Mockの動作を定義する
今回はMockの動作を定義します。設定するのはIntegration Request と Integration Response です。
Integration Request
こちらで、Methodのリクエストの内容を加工することができます。API Gatewayで受けたリクエストはそのまま利用できれば問題ありませんが、インターフェイスが異なる場合は、適宜変換してあげる必要があります。その役割を担うのが Integration Request です。
Integration Request をクリックします。開いた画面で Mapping Templates を展開します。application/json をクリックすると、API Gatewayで受け取ったリクエストをマッピングするためのテンプレートJsonが確認できます。
Mock Integrationを利用する場合は、必ず statusCode の値を入れる必要があります。そのため、こちらの値を削除するとMockの動作はエラーになりますのでご注意ください。
※このMapping Templatesは変更しないほうが良い
{"statusCode": 200}
Method Execution をクリックするとGETの設定画面へ戻ります。
Integration Response
こちらで、Mockから返却するレスポンスを定義します。こちらも前述のIntegration Requestと同じような役割を担っています。API Gatewayで中継された処理は、処理完了後にAPI Gatewayに返却されます。このレスポンスもAPI Gatewayのインターフェイスと合致している保証はありません。そのため、ここで返却値の加工を行うことができます。
Integration Response をクリックします。Mockで返却されるHTTP Statusが200のみ定義されているのが確認できます。Integration Requestとは少し様相が違いますね。Statusコードを複数用意したりする必要がある関係でしょうか。
HTTP Statusコード200の左端にある「▶」をクリックすると Integration Requestと同じく Mapping Templates が確認できます。
ヘッダもMappingによって改変できるようですが、今回はResponseのみ変更しましょう。
Mapping Templates を展開します。Integration Requestと同じく、application/json が定義されているのでこちらをクリックします。
application/json は Output passthrough と設定されているのが確認できます。こちらの設定の場合は、API Gatewayはレスポンスを特に加工せずにそのまま素通りさせます。
今回はMockサーバーとして動作させているため、API Gatewayは特に何の処理も起動していません。そのため、ここでMockとして動作させるデータを定義します。
本来、API Gatewayを通して別のAPIやLambdaを起動した場合、それらのレスポンスはAPI Gatewayの返却値にマッピングしてやる必要があります。返ってきた値がそのままの形で問題ないようであれば、Output passthrough を選択します。
Output passthroughの右にある ペンシルマークをクリックします。すると編集モードになるので、Output passthrough を Mapping template へ変更します。
TemplateにMockのレスポンスとして返却したいデータを定義します。今回は/users に対してのGETメソッドなので、それっぽいJSONの配列データを返すようにします。以下をTemplateに記載し、チェックボタンをクリックします。
[
{"id": 122, "name": "hoge"},
{"id": 298, "name": "fuga"}
]
Templateが保存されるので、Saveボタンをクリックします。
これで準備完了です。/users に対するGETメソッドのAPI作成が完了しました。
作成したAPIをテスト
早速テストしてみましょう。APIの道通確認は、コンソールのテスト機能を利用します。Method Execution（つまりは先程から触ってる設定画面）から選択できます。
Test をクリックします。APIのTestを実行する画面へ移動します。
今回は特に認証など設定していないので、Client Certificateの設定は不要です。引数などもないため、そのまま Test ボタンをクリックします。
先ほどIntegration Responseで設定したResponse Templatesが返却されていることが確認できます。正常に実行されたのが確認できました。
Logsには実行時のログが出力されますので、デバッグにとても有効な情報が入っています。Testに失敗した場合などはこちらを確認すると良いかと思います。
まとめ
今回は引数も何もない、単なるGETメソッドに反応するだけのとても単純なMockサーバーを作成してみました。こちらが基本中の基本になります。まだまだ色々と便利そうな機能がたくさんあるようです。次回以降は、URL引数, パラメータ化したパスの扱い、RequestによるResponseの分岐振り分け あたりをコツコツ書いていこうかと思います。
参照
脚注
- 気温が高いので結構重い雪ですが ↩
