2015-11-09 16 views
6

Ho una configurazione del gateway API AWS, servita da una funzione di Python Lambda. Per le risposte di successo Lambda restituisce una risposta della forma:.L'output Lambda del mapping nel gateway API fornisce l'errore del server

"200:{\"somekey\": \"somevalue\"}" 

Per impostazione predefinita, le integrazione di risposta impostazioni della console porta hanno una sola regola configurato con un Lambda errore Regex di * mappatura a uno stato di risposta di 200. Funziona bene.

Il problema si verifica quando provo a cambiarlo in 200. * (in modo da consentire l'avanzamento di codici più specifici). Ora ho un

{"message": "Internal server error"} 

ogni volta che mi ha colpito la porta d'ingresso con qualsiasi richiesta (con un conseguente 200 o meno).

Nessun log di errore viene scritto in CloudWatch.

enter image description here

voglio sapere come posso mappare le uscite lambda per codici di stato HTTP con successo in AWS gateway API.

+0

hai guarda a questo, sì? http://stackoverflow.com/questions/31329495/is-there-a-way-to-change-the-http-status-codes-amazon-api-gateway-returns/31371862#31371862 – Nefariis

risposta

10

Se fate un giro di prova nel gateway API, il registro di prova dovrebbe mostrare un errore simile a:

Sat Nov 21 07:41:25 UTC 2015 : Execution failed due to configuration error: No match for output mapping and no default output mapping configured

Il problema è che non c'è più a lungo una mappatura predefinita per la cattura di una risposta positiva. L'intenzione dell'eroga regex è di rilevare gli errori e mapparli ai codici di stato. L'errore regex cerca la proprietà errorMessage della risposta json non riuscita. Se si imposta il codice di stato 400 come predefinito (vuoto), la risposta corretta verrà sempre associata a un codice di stato di 400.

Si consiglia di lasciare 200 come predefinito (vuoto) regex. Quindi imposta valori regex specifici per verificare i diversi messaggi di errore. Ad esempio, è possibile avere più codici di stato di espressioni regolari di errori specifici e un generico catch-all per generare 500.

enter image description here

+0

Grazie per la spiegazione. Quello che sto vedendo è che non sono le "corrispondenze regex più specifiche" a essere considerate prioritarie; invece, sembra essere la mappatura più in fondo alla lista (con una regex che corrisponde al messaggio di errore) che viene utilizzata. Il tuo esempio funziona in entrambi i casi, ma ho pensato che valeva la pena sottolineare che il comportamento sembra essere diverso da quello che stai dicendo. –

+0

Grazie. Mi sembra sbagliato su questo. Ho appena fatto un sacco di test e non riesco a ottenere una priorità costante tra gli oggetti che corrispondono esattamente o che corrispondono esattamente. Probabilmente è meglio evitare qualsiasi cosa vicina. Modificherò la risposta per rimuovere il riferimento alla priorità. –

+0

"Il problema è che non esiste più una mappatura predefinita per ottenere una risposta positiva" - Hai un riferimento per questo? "Sarà meglio lasciare 200 come espressione regolare (vuota)". Ma hai detto che non funziona più, quindi perché? – Zigglzworth

2

Per coloro che hanno cercato tutto messo su questa questione e non poteva fare questo lavoro (come me), controllare il commento thedevkit su questo post (salvato la mia giornata):

https://forums.aws.amazon.com/thread.jspa?threadID=192918

riprodurlo interamente al di sotto:

I've had issues with this myself, and I believe that the newline characters are the culprit.

foo.* will match occurrences of "foo" followed by any characters EXCEPT newline. Typically this is solved by adding the '/s' flag, i.e. "foo.*/s", but the Lambda error regex doesn't seem to respect this.

As an alternative you can use something like: foo(.|\n)*

Problemi correlati