Creazione delle integrazioni proxy AWS Lambda per API HTTP in Gateway API
Un'integrazione proxy Lambda consente di integrare una route API con una funzione Lambda. Quando un client chiama l'API, API Gateway invia la richiesta alla funzione Lambda e restituisce la risposta della funzione al client. Per esempi di creazione di un'API HTTP, consultare Creazione di un'API HTTP.
Tipo di formato payload
La versione del formato del payload specifica il formato dell'evento che Gateway API invia a un'integrazione Lambda e il modo in cui Gateway API interpreta la risposta ricevuta da Lambda. Se non si specifica un tipo di formato payload, AWS Management Console utilizza la versione più recente per impostazione predefinita. Se si crea un'integrazione Lambda mediante la AWS CLI, AWS CloudFormation o SDK, è necessario specificare payloadFormatVersion
. I valori supportati sono 1.0
e 2.0
.
Per ulteriori informazioni su come impostare payloadFormatVersion
, consulta create-integration. Per ulteriori informazioni su come determinare l'entità payloadFormatVersion
di un'integrazione esistente, consulta get-integration.
Differenze di formato del payload
L'elenco seguente mostra le differenze tra le versioni del formato del payload 1.0
e 2.0
:
Il formato
2.0
non contiene i campimultiValueHeaders
omultiValueQueryStringParameters
. Le intestazioni duplicate sono combinate con virgole e incluse nel campoheaders
. Le stringhe di query duplicate sono combinate con virgole e incluse nel campoqueryStringParameters
.-
Il formato
2.0
includerawPath
. Se si utilizza una mappatura API per collegare la fase a un nome di dominio personalizzato,rawPath
non fornirà il valore di mappatura API. Utilizza il formato1.0
epath
per accedere alla mappatura API per il nome di dominio personalizzato. Il formato
2.0
include un nuovo campocookies
. Tutte le intestazioni dei cookie nella richiesta vengono combinate con virgole e aggiunte al campocookies
. Nella risposta al client, ogni cookie diventa un'intestazioneset-cookie
.
Struttura del formato del payload
Gli esempi seguenti mostrano la struttura di ogni tipo di formato payload. Per tutti i nomi delle intestazioni si utilizzano le minuscole.
Formato di risposta della funzione Lambda
Il tipo di formato del payload determina la struttura della risposta che deve essere restituita dalla funzione Lambda.
Risposta della funzione Lambda per il formato 1.0
Con la versione di formato 1.0
, le integrazioni Lambda devono restituire una risposta nel formato JSON seguente:
{ "isBase64Encoded": true|false, "statusCode": httpStatusCode, "headers": { "headername": "headervalue", ... }, "multiValueHeaders": { "headername": ["headervalue", "headervalue2", ...], ... }, "body": "..." }
Risposta della funzione Lambda per il formato 2.0
Con il tipo di formato 2.0
, API Gateway può dedurre autonomamente il formato della risposta. Se la funzione Lambda restituisce un JSON valido e non restituisce un , API Gateway fa le seguenti ipotes statusCode
:
-
isBase64Encoded
èfalse
. -
statusCode
è200
. -
content-type
èapplication/json
. -
body
è la risposta della funzione.
Gli esempi seguenti mostrano l'output di una funzione Lambda e l'interpretazione da parte di API Gateway.
Risultato della funzione Lambda | Interpretazione di API Gateway |
---|---|
|
|
|
|
Per personalizzare la risposta, la funzione Lambda deve restituire una risposta con il seguente formato.
{ "cookies" : ["
cookie1
", "cookie2
"], "isBase64Encoded": true|false, "statusCode":httpStatusCode
, "headers": { "headername
": "headervalue
", ... }, "body": "Hello from Lambda!
" }