API Gatewayのモックの統合が500

Question

で失敗私は実際にそれを呼び出すときに、私はAPIからそれを呼び出したときに動作しますが、ない方法/リソースのためのAPI Gatewayの統合を持っている：

$ aws apigateway test-invoke-method --rest-api-id $REST_API_ID \ 
    --resource-id $RESOURCE_ID --http-method GET | jq -r .log,.body 

これは罰金を動作し、私は、次のような出力が得られます。

Tue May 16 17:46:42 UTC 2017 : Starting execution for request: test-invoke-request 
Tue May 16 17:46:42 UTC 2017 : HTTP Method: GET, Resource Path: /status.json 
Tue May 16 17:46:42 UTC 2017 : Method request path: {} 
Tue May 16 17:46:42 UTC 2017 : Method request query string: {} 
Tue May 16 17:46:42 UTC 2017 : Method request headers: {} 
Tue May 16 17:46:42 UTC 2017 : Method request body before transformations: 
Tue May 16 17:46:42 UTC 2017 : Endpoint response body before transformations: 
Tue May 16 17:46:42 UTC 2017 : Endpoint response headers: {} 
Tue May 16 17:46:42 UTC 2017 : Method response body after transformations: { "statusCode": 200 } 
Tue May 16 17:46:42 UTC 2017 : Method response headers: {Content-Type=application/json} 
Tue May 16 17:46:42 UTC 2017 : Successfully completed execution 
Tue May 16 17:46:42 UTC 2017 : Method completed with status: 200 

{ "statusCode": 200 } 

しかし、私はapi.naftuli.wtf/v1/status.jsonである私のURL、でこれをアクセスすることはできません。私はglhf、stable、およびv1で定義されたステージを持っているので、それを置き換えると、異なる応答が表示されます。私は単純に、200 JSON BLOBを返すダミーレスポンスを必要とします。

私のリソースは、テキサスはhere as a Gistです。うまくいけば、これは私のAPI Gatewayの設定を完全に示してくれます。

これをCLIまたはWebコンソールからテストすると、予想通りの結果が得られます。私はapi.naftuli.wtfで私の展開APIからこれをカールしかし、もし、私は素敵な何かを得ることはありません：

$ for stage in glhf stable v1 ; do 
> url="https://api.naftuli.wtf/${stage}/status.json" 
> echo "${url}:" 
> curl -i -H 'Content-Type: application/json' \ 
>  https://api.naftuli.wtf/${stage}/status.json 
> echo -e '\n 
> done 
https://api.naftuli.wtf/glhf/status.json: 
HTTP/1.1 500 Internal Server Error 
Content-Type: application/json 
Content-Length: 36 
Connection: keep-alive 
Date: Tue, 16 May 2017 21:41:38 GMT 
x-amzn-RequestId: 712ba52b-3a80-11e7-9fec-b79b62d3bf7f 
X-Cache: Error from cloudfront 
Via: 1.1 da7a5d0ed7f424609000879e43743066.cloudfront.net (CloudFront) 
X-Amz-Cf-Id: hBwlbPCP9n2rlz53I-Qb9KoffHB_FoxUCZUaJYNnU3XhCWuMpQTP1Q== 

{"message": "Internal server error"} 

https://api.naftuli.wtf/stable/status.json: 
HTTP/1.1 403 Forbidden 
Content-Type: application/json 
Content-Length: 23 
Connection: keep-alive 
Date: Tue, 16 May 2017 21:41:38 GMT 
x-amzn-RequestId: 71561066-3a80-11e7-9b00-6700be628328 
x-amzn-ErrorType: ForbiddenException 
X-Cache: Error from cloudfront 
Via: 1.1 0c146399837c7d36c1f0f9d2636f8cf8.cloudfront.net (CloudFront) 
X-Amz-Cf-Id: ITX765xD8s4sNuOdXaJ2kPvqPo-w_dsQK3Sq_No130FAHxFuoVhO8w== 

{"message":"Forbidden"} 

https://api.naftuli.wtf/v1/status.json: 
HTTP/1.1 500 Internal Server Error 
Content-Type: application/json 
Content-Length: 36 
Connection: keep-alive 
Date: Tue, 16 May 2017 21:41:39 GMT 
x-amzn-RequestId: 7185fa99-3a80-11e7-a3b1-2f9e659fc361 
X-Cache: Error from cloudfront 
Via: 1.1 586f1a150b4ba39f3a668b8055d4d5ea.cloudfront.net (CloudFront) 
X-Amz-Cf-Id: dvnOa1s-YlwLSNzBfVyx5tSL6XrjFJM4_fES7MyTofykB3ReU5R1fg== 

{"message": "Internal server error"} 

段階の私の理解では、彼らがすべてのその下のベースパスに追加パスのプレフィックスたことでしたAPIリソースが利用可能でした。 /v1のパスを持つv1というステージがある場合、status.jsonのAPIゲートウェイリソースは、基本的には/v1の下にマップされ、/v1/status.jsonとなります。

いくつかのあいまいな理由で失敗しても、私はAPI Gatewayのベースパスのマッピングやステージがどのように働くか誤解されてもよいが、CloudWatchのは、コールが少なくとも起こっていることを私に伝えます：

21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Verifying Usage Plan for request: c5be3842-6af4-4725-a34f-d6eea8042d17. API Key: API Stage: tcips69qx2/prod_v1 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) API Key authorized because method 'GET /status.json' does not require API Key. Request will not contribute to throttle or quota limits 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Usage Plan check succeeded for API Key and API Stage tcips69qx2/prod_v1 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Starting execution for request: c5be3842-6af4-4725-a34f-d6eea8042d17 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) HTTP Method: GET, Resource Path: /v1/status.json 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Execution failed due to configuration error: statusCode should be an integer which defined in request template 
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Method completed with status: 500 

どうやらのみトラフィック全体V1ステージがCloudWatchログに到達しています。どこかに誤った設定があり、見つけられないようです。ゲートウェイは、あなたのintegration request templateで対応して返すようにステータスコードを探します

{ 
    "statusCode": 200 
} 

API：

Answer 1

あなたはこれに統合要求の設定でテンプレートを要求しようとすると、変更することができます。応答は、統合応答のマッピングテンプレートによって生成されます。私はあなたのテラフォームから、統合要求テンプレートに出力jsonファイルをロードしていることがわかります。これはAPI Gatewayが期待していないコンテンツです。

Answer 2

設定には少なくとも2つの異なる問題があります。

まず、3つの基本パスのマッピングの1つが、APIを呼び出す方法と一致しません。基本パスはステージ名と同じでなくても構いませんが、必要に応じて設定できます。ベースパスのマッピングにはベースパスとステージ名が含まれているため、APIゲートウェイはインボークパスにステージではなくベースパスマッピングを含めることを想定しているため、パスの[glhf stable v1]対応するベースパスマッピングエントリがAPIを決定し、使用するステージを決定する。これは、500を返すv1とglhfのベースパスでうまく動作します（別の問題を示しています）。安定した基本パス（https://api.naftuli.wtf/stable/status.json）は、ドメイン名api.naftuli.wtfに対して "安定"の基本パスが定義されていないため、403 Forbiddenを返します。安定ステージは「最新の」ベースパスにマップされるため、安定したステージを呼び出す方法はhttps://api.naftuli.wtf/latest/status.jsonとする必要があります。これは現在動作していません、なぜ私は分かりません。あなたがこれを実行している地域を教えてもらえれば、設定を参照してもっと掘り下げていくことができます。

第二の問題は、あなたのCloudWatchのログから、次のエントリで示されます。

Execution failed due to configuration error: statusCode should be an integer which defined in request template

は、あなたの統合要求テンプレート（「$ {ファイル（」$ {パス内のファイルにあなたの参照のことを確認することができます。モジュール} /files/status.json "）}"）には、トップレベルの属性として "statusCode：200"が含まれています。

私はまた、あなたが要求テンプレートと応答テンプレートの同じファイルを使用していることは驚くべきことがわかりました。ここでは特に変だった何

Answer 3

は、修正プログラムが各ステージのためのAWS CLIを使用してデプロイメントを作成するには、単純だった、明らかにしました。明らかに、Terraformは変更の展開や再展開をしていないため、私の変更は決してうまくいかなかった。