Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Crea integrazioni AWS Lambda proxy per API HTTP
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 Crea un'API HTTP.
Tipo di formato payload
La versione del formato payload specifica il formato dell'evento che API Gateway invia a un'integrazione Lambda e il modo in cui API Gateway interpreta la risposta di Lambda. Se non si specifica una versione del formato di payload, AWS Management Console utilizza la versione più recente per impostazione predefinita. Se crei un'integrazione Lambda utilizzando AWS CLI AWS CloudFormation, o un SDK, devi specificare un. payloadFormatVersion
I valori supportati sono 1.0
e 2.0
.
Per ulteriori informazioni su come impostare ilpayloadFormatVersion
, consulta create-integration. Per ulteriori informazioni su come determinare il livello payloadFormatVersion
di un'integrazione esistente, vedi get-integration
Differenze nel formato del payload
L'elenco seguente mostra le differenze tra le versioni del formato 1.0
e del 2.0
payload:
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
harawPath
. Se utilizzi una mappatura API per connettere lo stage a un nome di dominio personalizzato,rawPath
non fornirà il valore di mappatura dell'API. Utilizza format1.0
epath
per accedere alla mappatura API per il tuo 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. Tutti i nomi delle intestazioni sono in minuscolo.
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 1.0
in formato, le integrazioni Lambda devono restituire una risposta nel seguente formato JSON:
{ "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!
" }