AWS API Gatewayをアプリ側APIテストのスタブとして利用する

AWSのAPI GatewayをAPIサーバのフロントとして使うことができますが、API Gatewayの機能を使ってAPIテストのスタブとして機能させることも出来ます。

弊社では一部iOSアプリのAPI関連クラスのテストの接続先として活用しているプロジェクトがあります。

以下にその方法をご紹介します。

API GatewayでアプリAPIテストのスタブを作成する

まずは新しいAPIを作成します。
API名を入力し、APIの作成ボタンを押します。

APIが作成できたら、作成したAPIにリソースを追加していきます。
APIゲートウェイではAPIにパス指定のリソースを追加し、HTTPメソッドを定義することで使えるようになります。

リソース名、リソースパスを入力し、リソースの作成ボタンを押します。

次にメソッドを追加します。
以下の例ではGETリクエストを追加しますが、POST、PUT、DELETEなども追加できます。

画面上部のアクションからメソッドの作成を選択し、リストからGETを選択し、チェックマークの画像をクリックします。

統合タイプの中からMockを選択し、保存ボタンを押します。

次にレスポンスを追加します。
レスポンスは、JSONテキストなどを貼り付けてレスポンスとして返すことができます。

統合レスポンスをクリックしてレスポンスの画面を開きます。

本文マッピングテンプレートを展開して、右下にレスポンスとして返却させるJSONなどを貼り付けたあと、右下の保存ボタンを押します。

リソースなどを追加したあと、有効にするためにはAPIをデプロイする必要があります。
アクションからAPIをデプロイを選択します。

デプロイするステージ名を入力して（既にステージがある場合は選択して）デプロイボタンを押します。

以上、一連の流れのご紹介でした。

POSTリクエストなども同じ手順で追加できますが、例えばPOSTリクエストの場合、リクエスト側がリクエストヘッダに指定してくるコンテンツタイプなどがGETと違ったりする場合があるため、その場合は調整が必要です。

例えばアプリからPOSTリクエストする際にコンテンツタイプに「application/x-www-form-urlencoded」を指定していた場合、リクエストに合わせた設定にする必要があります。
何も指定せずにAPI Gatewayで設定された内容とリクエストヘッダの内容が食い違った場合、正しくレスポンスが返却されません。
この例では、デフォルトでコンテンツタイプがapplication/jsonになっているため、そのままPOSTリクエストを登録すると、例えば「application/x-www-form-urlencoded」をコンテンツタイプにセットしてアクセスした際にInternal Server Errorになります。

この問題は実際にとあるプロジェクトで起こりました。
そのプロジェクトでは、iOSアプリからはPOSTリクエストを送信した際にBODYがある場合はコンテンツタイプが「application/x-www-form-urlencoded」で、BODYが無い場合は「application/json」になっているため、BODYがあるPOSTだけテストが通らずに少しハマりました。

POSTのコンテンツタイプは以下のようにして設定できます。