API-Gateway Mock Integration schlägt mit 500

Question

Ich habe eine API-Gateway-Integration für ein Verfahren/Ressource, die funktioniert, wenn ich es von der API aufrufen, aber nicht, wenn ich es eigentlich nennen:

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

Dies funktioniert gut und ich erhalte die folgende Ausgabe:

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 } 

Allerdings kann ich nicht diese Zugriff auf meine URL, die api.naftuli.wtf/v1/status.json ist. Ich habe Stufen definiert um glhf, stable und v1, so dass durch das Ersetzen, Sie verschiedene Antworten sehen werden. Ich möchte einfach eine Dummy-Antwort, die einen 200 JSON-Blob zurückgibt.

Meine Terraform für die Ressourcen ist here as a Gist. Hoffentlich zeigt dies vollständig meine API Gateway-Konfiguration.

Wenn ich Test von der CLI oder von der Webkonsole aus aufrufen, bekomme ich zurück, was erwartet wird. Allerdings, wenn ich das von meinem Einsatz API bei api.naftuli.wtf kräuseln, bekomme ich nichts schön:

$ 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"} 

Mein Verständnis von Stufen waren, dass sie auf dem Basispfad zusätzlichen Pfad-Präfixe waren, unter denen alle API-Ressourcen waren verfügbar. Wenn ich eine Stufe namens v1 mit einem Pfad von /v1 hätte, würde ich erwarten, dass eine API-Gateway-Ressource für status.json grundsätzlich unter /v1 zugeordnet wird, was /v1/status.json ergibt.

Ich kann Missverständnis, wie API-Gateway Basispfadzuordnungen und Stufen arbeiten, aber Cloudwatch sagt mir, dass der Anruf zumindest geschieht, wenn auch aus unerfindlichen Gründen versagt:

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 

Offenbar nur Verkehr über Die V1-Phase erreicht die CloudWatch-Protokolle. Ich habe irgendwo eine Fehlkonfiguration und ich kann es nicht finden.

Answer 1

können Sie versuchen, und ändern Sie Vorlage in der Integration Anfrage Setup diese Anfrage:

{ 
    "statusCode": 200 
} 

API-Gateway sucht nach dem Statuscode der Antwort in Ihrem integration request template zurückzukehren. Die Antwort wird von der Zuordnungsvorlage in der Integrationsantwort generiert. Ich kann von Ihrem Terraform-Setup sehen, dass Sie die Ausgabe-JSON-Datei in die Integrationsanforderungsvorlage laden. Dies ist der Inhalt, den API Gateway nicht erwartet.

Answer 2

Sie haben mindestens zwei unterschiedliche Probleme mit Ihrer Konfiguration.

Erstens entspricht eine Ihrer drei Basispfadzuordnungen nicht der Art, wie Sie Ihre API aufrufen. Beachten Sie, dass die Basispfade nicht mit Ihren Stage-Namen übereinstimmen müssen, sie können jedoch auch beliebig sein. Da Ihre Basispfadzuordnungen Basispfade und Stufennamen enthalten, erwartet das API Gateway, dass der Aufrufpfad eine Basispfadzuordnung und keine Stufe enthält. Daher interpretiert es den Abschnitt [glhf stable v1] Ihres Pfads als Basispfad und sucht für den entsprechenden Basispfadzuordnungseintrag, um die zu verwendende API und Phase zu bestimmen. Dies funktioniert gut für die Basispfade v1 und glhf, die 500 zurückgeben (was auf ein anderes Problem hinweist). Der stabile Basispfad (in https://api.naftuli.wtf/stable/status.json) gibt 403 Forbidden zurück, da für den Domänennamen api.naftuli.wtf kein Basispfad von "stable" definiert ist. Die stabile Stufe wird dem "neuesten" Basispfad zugeordnet, daher sollte der Aufruf der stabilen Stufe der Aufruf https://api.naftuli.wtf/latest/status.json sein.Dies funktioniert derzeit nicht, und ich weiß nicht warum. Wenn Sie mir sagen, in welcher Region Sie das ausführen, kann ich die Konfiguration nachschlagen und mehr graben.

Das zweite Problem wird durch den folgenden Eintrag aus dem Cloudwatch-Protokollen angezeigt:

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

Können Sie überprüfen Ihre Referenz in "$ {file (" $ {path, dass Ihre Vorlage Integration Anfrage (in der Datei. modul} /files/status.json ")}" enthält "statusCode: 200" als Attribut der obersten Ebene.

Ich fand es auch überraschend, dass Sie die gleiche Datei für eine Anfrage Vorlage und eine Antwortvorlage verwenden.

Answer 3

Was hier besonders merkwürdig war, war offensichtlich, die Lösung bestand einfach darin, für jede Stufe eine Implementierung mit der AWS-CLI zu erstellen. Anscheinend hat Terraform die Bereitstellungen bei Änderungen nicht aktualisiert oder neu gestartet, und so sind meine Änderungen nie zustande gekommen.