Creación de integraciones de proxy de AWS Lambda para las API de HTTP en API Gateway
Una integración de proxy de Lambda le permite integrar una ruta de API con una función de Lambda. Cuando un cliente llama a la API, API Gateway envía la solicitud a la función de Lambda y devuelve la respuesta de la función al cliente. Para obtener ejemplos de creación de una API HTTP, consulte Creación de una API de HTTP.
Versión de formato de carga
La versión del formato de carga especifica el formato del evento que API Gateway envía a una integración de Lambda y cómo API Gateway interpreta la respuesta de Lambda. Si no especifica una versión de formato de carga, la AWS Management Console utiliza la versión más reciente de forma predeterminada. Si crea una integración de Lambda utilizando la AWS CLI, AWS CloudFormation o un SDK, debe especificar una payloadFormatVersion
. Los valores admitidos son 1.0
y 2.0
.
Para obtener más información sobre cómo establecer payloadFormatVersion
, consulte create-integration. Para obtener más información sobre cómo determinar la payloadFormatVersion
de una integración existente, consulte get-integration.
Diferencias de formato de carga
En la siguiente lista, se muestran las diferencias entre las versiones del formato de carga 1.0
y 2.0
:
El formato
2.0
no tiene camposmultiValueHeaders
omultiValueQueryStringParameters
. Los encabezados duplicados se combinan con comas y se incluyen en el campoheaders
. Las cadenas de consulta duplicadas se combinan con comas y se incluyen en el campoqueryStringParameters
.-
El formato
2.0
tienerawPath
. Si utiliza una asignación de API para conectar su escenario a un nombre de dominio personalizado,rawPath
no proporcionará el valor de asignación de la API. Use el formato1.0
ypath
para acceder a la asignación de la API para su nombre de dominio personalizado. El formato
2.0
incluye un nuevo campocookies
. Todos los encabezados de cookies en la solicitud se combinan con comas y se agregan al campocookies
. En la respuesta al cliente, cada cookie se convierte en un encabezadoset-cookie
.
Estructura de formato de carga
Los siguientes ejemplos muestran la estructura de cada versión de formato de carga. Todos los nombres de encabezado están en minúsculas.
Formato de respuesta de función de Lambda
La versión del formato de carga determina la estructura de la respuesta que debe devolver su función de Lambda.
Respuesta de función de Lambda para el formato 1.0
Con la versión de formato 1.0
, las integraciones de Lambda deben devolver una respuesta en el siguiente formato JSON:
{ "isBase64Encoded": true|false, "statusCode": httpStatusCode, "headers": { "headername": "headervalue", ... }, "multiValueHeaders": { "headername": ["headervalue", "headervalue2", ...], ... }, "body": "..." }
Respuesta de función de Lambda para el formato 2.0
Con la versión de formato 2.0
, API Gateway puede inferir el formato de respuesta por usted. API Gateway hace las siguientes suposiciones si su función de Lambda devuelve JSON válido y no devuelve un statusCode
:
-
isBase64Encoded
esfalse
. -
statusCode
es200
. -
content-type
esapplication/json
. -
body
es la respuesta de la función.
Los siguientes ejemplos muestran el resultado de una función de Lambda y la interpretación de API Gateway.
Salida de función de Lambda | Interpretación de API Gateway |
---|---|
|
|
|
|
Para personalizar la respuesta, su función de Lambda debe devolver una respuesta con el siguiente formato.
{ "cookies" : ["
cookie1
", "cookie2
"], "isBase64Encoded": true|false, "statusCode":httpStatusCode
, "headers": { "headername
": "headervalue
", ... }, "body": "Hello from Lambda!
" }