# Integraciones de Lambda para las API de REST en API Gateway
Puede integrar un método de API con una función de Lambda mediante la integración de proxy de Lambda o la integración de Lambda que no sea de proxy (personalizada).
En la integración de proxy de Lambda, la configuración requerida es sencilla. Establezca el método HTTP de la integración en POST, la URI del punto de conexión de la integración en el ARN de la acción de invocación de una función de Lambda específica y otorgue permisos a API Gateway para llamar a la función de Lambda en su nombre.
En la integración de Lambda que no sea de proxy, además de los pasos de configuración de integración de proxy, también debe especificar cómo se asignan los datos entrantes a la solicitud de integración y cómo se asignan los datos resultantes de respuesta de la integración a la respuesta de método.
**Topics**
+ [Integraciones de proxy de Lambda en API Gateway](set-up-lambda-proxy-integrations.md)
+ [Configuración de integraciones de Lambda personalizadas en API Gateway](set-up-lambda-custom-integrations.md)
+ [Configurar la invocación asíncrona de la función de Lambda de backend](set-up-lambda-integration-async.md)
+ [Gestionar los errores de Lambda en API Gateway](handle-errors-in-lambda-integration.md)
# Integraciones de proxy de Lambda en API Gateway
En la siguiente sección se muestra cómo utilizar una integración de proxy de Lambda.
**Topics**
+ [Descripción de la integración de proxy de Lambda en API Gateway](#api-gateway-create-api-as-simple-proxy)
+ [Compatibilidad con encabezados de varios valores y parámetros de cadenas de consulta](#apigateway-multivalue-headers-and-parameters)
+ [Formato de entrada de una función de Lambda para la integración de proxy](#api-gateway-simple-proxy-for-lambda-input-format)
+ [Formato de salida de una función de Lambda para la integración de proxy](#api-gateway-simple-proxy-for-lambda-output-format)
+ [Configuración de una integración de proxy de Lambda para API Gateway mediante la AWS CLI](set-up-lambda-proxy-integration-using-cli.md)
+ [Configuración de un recurso de proxy con la integración de proxy de Lambda con una definición OpenAPI](api-gateway-set-up-lambda-proxy-integration-on-proxy-resource.md)
## Descripción de la integración de proxy de Lambda en API Gateway
La integración de proxy de Lambda de Amazon API Gateway es un mecanismo sencillo, potente y ágil para desarrollar una API con la configuración de un solo método de API. La integración de proxy de Lambda permite al cliente llamar a una única función de Lambda en el backend. La función obtiene acceso a muchos recursos o características de otros servicios de AWS, incluidas las llamadas a otras funciones de Lambda.
En la integración de proxy de Lambda, cuando un cliente envía una solicitud de API, API Gateway pasa a la función de Lambda integrada un [evento de objeto](#api-gateway-simple-proxy-for-lambda-input-format), salvo que no se conserve el orden de los parámetros de la solicitud. Estos [datos de la solicitud](#api-gateway-simple-proxy-for-lambda-input-format) incluyen los encabezados de solicitud, los parámetros de cadena de consulta, las variables de ruta de la URL, la carga y los datos de configuración de la API. Los datos de configuración pueden incluir el nombre de la etapa de implementación actual, las variables de la etapa, la identidad del usuario o el contexto de autorización (si lo hubiera). La función de Lambda del backend analiza los datos de la solicitud entrante para determinar la respuesta que devuelve. Para que API Gateway transmita la salida de Lambda como la respuesta de la API al cliente, la función de Lambda debe devolver el resultado en [este formato](#api-gateway-simple-proxy-for-lambda-output-format).
Dado que API Gateway no interviene mucho entre el cliente y la función de Lambda del backend para la integración de proxy de Lambda, el cliente y la función de Lambda integrada pueden adaptarse a los cambios de cada uno sin interrumpir la configuración de integración existente de la API. Para habilitar esto, el cliente debe seguir los protocolos de aplicación promulgados por la función de Lambda del backend.
Puede configurar una integración de proxy de Lambda para cualquier método de API. Sin embargo, una integración de proxy de Lambda es más potente cuando se configura para un método de API que implica un recurso de proxy genérico. El recurso de proxy genérico se puede indicar mediante una variable especial de ruta basada en plantilla de `{proxy+}`, el marcador de posición del método catch-all `ANY` o ambos. El cliente puede transmitir la entrada a la función de Lambda del backend en la solicitud entrante según lo soliciten los parámetros o la carga aplicable. Los parámetros de solicitud incluyen encabezados, variables de ruta de la URL, parámetros de cadenas de consulta y la carga aplicable. La función de Lambda integrada verifica todas las fuentes de entrada antes de procesar la solicitud y de responder al cliente con mensajes de error importantes si falta alguna de las entradas requeridas.
Al llamar a un método de API integrado con el método HTTP genérico de `ANY` y el recurso genérico de `{proxy+}`, el cliente envía una solicitud con un método HTTP específico en lugar de `ANY`. El cliente también especifica una ruta de URL específica en lugar de `{proxy+}` e incluye cualquier encabezado, parámetro de cadena de consulta o una carga aplicable.
En la siguiente lista se resumen los comportamientos de tiempo de ejecución de los diferentes métodos de API con la integración de proxy de Lambda:
+ `ANY /{proxy+}`: el cliente debe elegir un método HTTP específico, debe establecer una jerarquía de ruta de recursos específica y puede establecer cualquier encabezado, parámetro de cadena de consulta y carga aplicable para transmitir los datos como entrada a la función de Lambda integrada.
+ `ANY /res`: el cliente debe elegir un método HTTP específico y puede establecer cualquier encabezado, parámetro de cadena de consulta y carga aplicable para transmitir los datos como entrada a la función de Lambda integrada.
+ `GET|POST|PUT|... /{proxy+}`: el cliente puede establecer una jerarquía de ruta de recursos específica, cualquier encabezado, parámetro de cadena de consulta y carga aplicable para transmitir los datos como entrada a la función de Lambda integrada.
+ `GET|POST|PUT|... /res/{path}/...`: el cliente debe elegir un segmento de ruta específico (para la variable `{path}`) y puede establecer cualquier encabezado de solicitud, parámetro de cadena de consulta y carga aplicable para transmitir los datos de entrada a la función de Lambda integrada.
+ `GET|POST|PUT|... /res`: el cliente puede elegir cualquier encabezado de solicitud, parámetro de cadena de consulta y carga aplicable para transmitir los datos de entrada a la función de Lambda integrada.
Tanto el recurso de proxy de `{proxy+}` como el recurso personalizado de `{custom}` se expresan como variables de ruta basada en plantilla. Sin embargo, `{proxy+}` puede hacer referencia a cualquier recurso en una jerarquía de ruta, mientras que `{custom}` se refiere únicamente a un segmento de ruta específico. Por ejemplo, una tienda de comestibles podría organizar un inventario de productos en línea por nombres de departamento, categorías de productos y tipos de productos. El sitio web de la tienda de comestibles puede entonces representar los productos disponibles con las siguientes variables de ruta basada en plantilla para los recursos personalizados: `/{department}/{produce-category}/{product-type}`. Por ejemplo, las manzanas están representadas con `/produce/fruit/apple` y las zanahorias con `/produce/vegetables/carrot`. También puede utilizar `/{proxy+}` para representar a cualquier departamento, cualquier categoría de producto o cualquier tipo de producto que un cliente puede buscar mientras realiza sus compras en la tienda en línea. Por ejemplo, `/{proxy+}` puede hacer referencia a cualquiera de los siguientes elementos:
+ `/produce`
+ `/produce/fruit`
+ `/produce/vegetables/carrot`
Para que los clientes puedan buscar cualquier producto disponible, su categoría de producto y el departamento asociado en la tienda, puede exponer un único método de `GET /{proxy+}` con permisos de solo lectura. Del mismo modo, para permitir que un supervisor actualice el inventario del departamento `produce`, puede configurar otro método único de `PUT /produce/{proxy+}` con permisos de lectura y escritura. Para permitir que un cajero actualice el total de unidades de una verdura, puede configurar un método `POST /produce/vegetables/{proxy+}` con permisos de lectura y escritura. Para que el gerente de una tienda pueda realizar cualquier acción posible en cualquier producto disponible, el desarrollador de la tienda en línea puede exponer el método `ANY /{proxy+}` con permisos de lectura y escritura. En cualquier caso, en el tiempo de ejecución, el cliente o el empleado debe seleccionar un producto específico de un tipo determinado en un departamento elegido o en un departamento específico.
Para obtener más información acerca de la configuración de las integraciones del proxy de API Gateway, consulte [Configuración de una integración de proxy con un recurso de proxy](api-gateway-set-up-simple-proxy.md).
La integración del proxy requiere que el cliente tenga un conocimiento más detallado de los requisitos del backend. Por lo tanto, para garantizar un óptimo rendimiento de la aplicación y experiencia del usuario, el desarrollador del backend debe comunicar con claridad al desarrollador del cliente los requisitos del backend y proporcionar un mecanismo de comentarios de errores sólido cuando los requisitos no se cumplan.
## Compatibilidad con encabezados de varios valores y parámetros de cadenas de consulta
API Gateway ahora es compatible con varios encabezados y parámetros de cadena de consulta que tengan el mismo nombre. Los encabezados de varios valores y los encabezados y parámetros de un solo valor se pueden combinar en las mismas solicitudes y respuestas. Para obtener más información, consulte [Formato de entrada de una función de Lambda para la integración de proxy](#api-gateway-simple-proxy-for-lambda-input-format) y [Formato de salida de una función de Lambda para la integración de proxy](#api-gateway-simple-proxy-for-lambda-output-format).
## Formato de entrada de una función de Lambda para la integración de proxy
Con la integración de proxy de Lambda, API Gateway asigna toda la solicitud de cliente al parámetro de entrada `event` de la función de Lambda del backend. En el siguiente ejemplo, se muestra la estructura de un evento que API Gateway envía a una integración de proxy de Lambda.
En este ejemplo, suponemos que la invocación a API Gateway fue la siguiente:
```
curl 'https://a1b2c3.execute-api.us-east-1.amazonaws.com/my/path?parameter1=value1¶meter2=value1¶meter2=value2¶meter3=value1,value2' -H 'header1: value1' -H 'header2: value1' -H 'header2: value2' -H 'header3: value1,value2'
```
El resultado es similar al siguiente:
```
{
"resource": "/my/path",
"path": "/my/path",
"httpMethod": "GET",
"headers": {
"header1": "value1",
"header2": "value2",
"header3": "value1,value2"
},
"multiValueHeaders": {
"header1": ["value1"],
"header2": ["value1","value2"],
"header3": ["value1,value2"]
},
"queryStringParameters": {
"parameter1": "value1",
"parameter2": "value2",
"parameter3": "value1,value2"
},
"multiValueQueryStringParameters": {
"parameter1": ["value1"],
"parameter2": ["value1","value2"],
"parameter3": ["value1,value2"]
},
"requestContext": {
"accountId": "123456789012",
"apiId": "id",
"authorizer": {
"claims": null,
"scopes": null
},
"domainName": "id.execute-api.us-east-1.amazonaws.com",
"domainPrefix": "id",
"extendedRequestId": "request-id",
"httpMethod": "GET",
"identity": {
"accessKey": null,
"accountId": null,
"caller": null,
"cognitoAuthenticationProvider": null,
"cognitoAuthenticationType": null,
"cognitoIdentityId": null,
"cognitoIdentityPoolId": null,
"principalOrgId": null,
"sourceIp": "IP",
"user": null,
"userAgent": "user-agent",
"userArn": null,
"clientCert": {
"clientCertPem": "CERT_CONTENT",
"subjectDN": "www.example.com",
"issuerDN": "Example issuer",
"serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1",
"validity": {
"notBefore": "May 28 12:30:02 2019 GMT",
"notAfter": "Aug 5 09:36:04 2021 GMT"
}
}
},
"path": "/my/path",
"protocol": "HTTP/1.1",
"requestId": "id=",
"requestTime": "04/Mar/2020:19:15:17 +0000",
"requestTimeEpoch": 1583349317135,
"resourceId": null,
"resourcePath": "/my/path",
"stage": "$default"
},
"pathParameters": null,
"stageVariables": null,
"body": "Hello from Lambda!",
"isBase64Encoded": false
}
```
**nota**
En la entrada:
La clave `headers` solo puede contener encabezados de un solo valor.
La clave `multiValueHeaders` puede contener encabezados de varios valores y encabezados de un solo valor.
Si especifica valores para `headers` y `multiValueHeaders`, API Gateway los combina en una sola lista. Si se especifica el mismo par de clave-valor en ambos, solo los valores de `multiValueHeaders` aparecerán en la lista combinada.
En la entrada a la función de Lambda de backend, el objeto `requestContext` es un mapa de pares de clave-valor. En cada par, la clave es el nombre de una propiedad de la variable [\$1context](api-gateway-mapping-template-reference.md#context-variable-reference) y el valor es el valor de esa propiedad. API Gateway podría agregar nuevas claves al mapa.
En función de las características habilitadas, el mapa `requestContext` puede variar de API en API. Por ejemplo, en el ejemplo anterior, no se especifica ningún tipo de autorización, por lo que no hay propiedades `$context.authorizer.*` o `$context.identity.*` presentes. Cuando se especifica un tipo de autorización, esto hace que API Gateway transfiera información del usuario autorizado al punto de conexión de integración en un objeto `requestContext.identity` tal y como se indica a continuación:
+ Cuando el tipo de autorización es `AWS_IAM`, la información del usuario autorizado incluye propiedades `$context.identity.*`.
+ Cuando el tipo de autorización es `COGNITO_USER_POOLS` (autorizador de Amazon Cognito), la información del usuario autorizado incluye las propiedades `$context.identity.cognito*` y `$context.authorizer.claims.*`.
+ Cuando el tipo de autorización es `CUSTOM` (autorizador de Lambda), la información del usuario autorizado incluye las propiedades `$context.authorizer.principalId` y otras propiedades `$context.authorizer.*` aplicables.
## Formato de salida de una función de Lambda para la integración de proxy
Con la integración de proxy de Lambda, API Gateway requiere que la función de Lambda del backend devuelva la salida de acuerdo con el siguiente formato JSON:
```
{
"isBase64Encoded": true|false,
"statusCode": httpStatusCode,
"headers": { "headerName": "headerValue", ... },
"multiValueHeaders": { "headerName": ["headerValue", "headerValue2", ...], ... },
"body": "..."
}
```
En la salida:
+ Las claves `headers` y `multiValueHeaders` pueden no estar especificadas si no se van a devolver más encabezados de respuesta.
+ La clave `headers` solo puede contener encabezados de un solo valor.
+ La clave `multiValueHeaders` puede contener encabezados de varios valores y encabezados de un solo valor. Puede utilizar la clave `multiValueHeaders` para especificar todos los encabezados adicionales, incluidos los que solo contienen un valor.
+ Si especifica valores para `headers` y `multiValueHeaders`, API Gateway los combina en una sola lista. Si se especifica el mismo par de clave-valor en ambos, solo los valores de `multiValueHeaders` aparecerán en la lista combinada.
Para habilitar CORS para la integración de proxy de Lambda, debe agregar `Access-Control-Allow-Origin:domain-name` a la salida `headers`. `domain-name` puede ser `*` para cualquier nombre de dominio. La salida `body` se serializa en el frontend como la carga de respuesta del método. Si `body` es un blob binario, puede codificarlo como una cadena codificada en Base64 estableciendo `isBase64Encoded` en `true` y configurando `*/*` como **Binary Media Type (Tipo de medio binario)**. De lo contrario, puede establecerlo en `false` o dejarlo sin especificar.
**nota**
Para obtener más información acerca de cómo habilitar la compatibilidad con datos binarios, consulte [Habilitar la compatibilidad con datos binarios mediante la consola de API Gateway](api-gateway-payload-encodings-configure-with-console.md). Para ver una función de Lambda de ejemplo, consulte [Devolución de medios binarios desde una integración de proxy de Lambda en API Gateway](lambda-proxy-binary-media.md).
Si la salida de la función tiene un formato diferente, API Gateway devuelve una respuesta de error `502 Bad Gateway`.
Para devolver una respuesta en una función de Lambda de Node.js, puede utilizar comandos como los siguientes:
+ Para devolver un resultado correcto, llame a `callback(null, {"statusCode": 200, "body": "results"})`.
+ Para producir una excepción, llame a `callback(new Error('internal server error'))`.
+ En caso de que se produzca un error del lado del cliente (por ejemplo, si falta un parámetro necesario), puede llamar a `callback(null, {"statusCode": 400, "body": "Missing parameters of ..."})` para devolver el error sin iniciar una excepción.
En una función de Lambda de `async` de Node.js, la sintaxis correspondiente sería:
+ Para devolver un resultado correcto, llame a `return {"statusCode": 200, "body": "results"}`.
+ Para producir una excepción, llame a `throw new Error("internal server error")`.
+ En caso de que se produzca un error del lado del cliente (por ejemplo, si falta un parámetro necesario), puede llamar a `return {"statusCode": 400, "body": "Missing parameters of ..."}` para devolver el error sin iniciar una excepción.
# Configuración de una integración de proxy de Lambda para API Gateway mediante la AWS CLI
En esta sección mostramos cómo configurar una API con la integración de proxy de Lambda mediante la AWS CLI. Para obtener instrucciones detalladas acerca de cómo utilizar la consola de API Gateway para configurar un recurso de proxy con la integración de proxy de Lambda, consulte [Tutorial: Creación de una API de REST con una integración de proxy de Lambda](api-gateway-create-api-as-simple-proxy-for-lambda.md).
Como ejemplo, utilizaremos la siguiente función de Lambda de muestra como el backend de la API:
```
export const handler = async(event, context) => {
console.log('Received event:', JSON.stringify(event, null, 2));
var res ={
"statusCode": 200,
"headers": {
"Content-Type": "*/*"
}
};
var greeter = 'World';
if (event.greeter && event.greeter!=="") {
greeter = event.greeter;
} else if (event.body && event.body !== "") {
var body = JSON.parse(event.body);
if (body.greeter && body.greeter !== "") {
greeter = body.greeter;
}
} else if (event.queryStringParameters && event.queryStringParameters.greeter && event.queryStringParameters.greeter !== "") {
greeter = event.queryStringParameters.greeter;
} else if (event.multiValueHeaders && event.multiValueHeaders.greeter && event.multiValueHeaders.greeter != "") {
greeter = event.multiValueHeaders.greeter.join(" and ");
} else if (event.headers && event.headers.greeter && event.headers.greeter != "") {
greeter = event.headers.greeter;
}
res.body = "Hello, " + greeter + "!";
return res
};
```
Si se compara con la configuración de la integración personalizada de Lambda en [Configuración de integraciones de Lambda personalizadas en API Gateway](set-up-lambda-custom-integrations.md), la entrada de esta función de Lambda se puede expresar en los parámetros de la solicitud y en el cuerpo. Tiene más libertad para permitir al cliente transferir los mismos datos de entrada. En este caso el cliente puede transferir el nombre de greeter como un parámetro de cadena de consulta, un encabezado o una propiedad del cuerpo. La función también puede admitir la integración de Lambda personalizada. La configuración de la API es más sencilla. No se configura ninguna respuesta de método ni de integración.
**Para configurar una integración de proxy de Lambda mediante la AWS CLI**
1. Utilice el siguiente comando [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) para crear una API privada:
```
aws apigateway create-rest-api --name 'HelloWorld (AWS CLI)'
```
El resultado será similar al siguiente:
```
{
"name": "HelloWorldProxy (AWS CLI)",
"id": "te6si5ach7",
"rootResourceId" : "krznpq9xpg",
"createdDate": 1508461860
}
```
En este ejemplo, se utiliza el `id` de API (`te6si5ach7`) y el `rootResourceId` (`krznpq9xpg`).
1. Utilice el siguiente comando [create-resource](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-resource.html) para crear un [recurso](https://docs.aws.amazon.com/apigateway/latest/api/API_Resource.html) de `/greeting` de API Gateway:
```
aws apigateway create-resource \
--rest-api-id te6si5ach7 \
--parent-id krznpq9xpg \
--path-part {proxy+}
```
El resultado será similar al siguiente:
```
{
"path": "/{proxy+}",
"pathPart": "{proxy+}",
"id": "2jf6xt",
"parentId": "krznpq9xpg"
}
```
Debe usar el valor `id` del recurso `{proxy+}` (`2jf6xt`) para crear un método en el recurso `/{proxy+}` en el siguiente paso.
1. Utilice el siguiente comando [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) para crear una solicitud de método `ANY` de `ANY /{proxy+}`:
```
aws apigateway put-method --rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method ANY \
--authorization-type "NONE"
```
El resultado será similar al siguiente:
```
{
"apiKeyRequired": false,
"httpMethod": "ANY",
"authorizationType": "NONE"
}
```
Este método de API permite al cliente recibir o enviar saludos de la función de Lambda al backend.
1. Utilice el siguiente comando [put-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration.html) para configurar la integración del método `ANY /{proxy+}` con una función de Lambda denominada `HelloWorld`. Esta función responde a la solicitud con un mensaje de `"Hello, {name}!"`, si se proporciona el parámetro `greeter`, o bien `"Hello, World!"`, si no se ha establecido el parámetro de cadena de consulta.
```
aws apigateway put-integration \
--rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method ANY \
--type AWS_PROXY \
--integration-http-method POST \
--uri arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123456789012:function:HelloWorld/invocations \
--credentials arn:aws:iam::123456789012:role/apigAwsProxyRole
```
**importante**
Para las integraciones Lambda, debe utilizar el método HTTP de `POST` para la solicitud de integración, según la [especificación de la acción del servicio de Lambda para las invocaciones de funciones](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). El rol de IAM de `apigAwsProxyRole` debe tener políticas que permitan al servicio `apigateway` invocar funciones Lambda. Para obtener más información sobre los permisos de IAM, consulte [Modelo de permisos de API Gateway para invocar una API](permissions.md#api-gateway-control-access-iam-permissions-model-for-calling-api).
El resultado será similar al siguiente:
```
{
"passthroughBehavior": "WHEN_NO_MATCH",
"cacheKeyParameters": [],
"uri": "arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:1234567890:function:HelloWorld/invocations",
"httpMethod": "POST",
"cacheNamespace": "vvom7n",
"credentials": "arn:aws:iam::1234567890:role/apigAwsProxyRole",
"type": "AWS_PROXY"
}
```
En lugar de proporcionar un rol de IAM para `credentials`, puede utilizar el comando [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) para agregar permisos basados en recursos. Esto es lo que hace la consola de API Gateway.
1. Utilice el siguiente comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-deployment.html) para implementar la API en una etapa `test`:
```
aws apigateway create-deployment \
--rest-api-id te6si5ach7 \
--stage-name test
```
1. Pruebe la API mediante los siguientes comandos cURL en un terminal.
Llame a la API con el parámetro de cadena de consulta de `?greeter=jane`:
```
curl -X GET 'https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/greeting?greeter=jane'
```
Llame a la API con un parámetro de encabezado de `greeter:jane`:
```
curl -X GET https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/hi \
-H 'content-type: application/json' \
-H 'greeter: jane'
```
Llame a la API con un cuerpo de `{"greeter":"jane"}`:
```
curl -X POST https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/hi \
-H 'content-type: application/json' \
-d '{ "greeter": "jane" }'
```
En todos estos casos, la salida es una respuesta 200 con el siguiente cuerpo de respuesta:
```
Hello, jane!
```
# Configuración de un recurso de proxy con la integración de proxy de Lambda con una definición OpenAPI
Para configurar un recurso de proxy con el tipo de integración de proxy de Lambda, cree un recurso de API con un parámetro de ruta expansiva (por ejemplo, `/parent/{proxy+}`) e integre este recurso con un backend de funciones Lambda (por ejemplo, `arn:aws:lambda:us-west-2:123456789012:function:SimpleLambda4ProxyResource`) en el método `ANY`. El parámetro de ruta expansiva debe estar al final de la ruta del recurso de la API. Al igual que con un recurso que no es de proxy, puede configurar el recurso de proxy mediante la consola de API Gateway importando un archivo de definición de OpenAPI o llamando directamente a la API REST de API Gateway.
El siguiente archivo de definición de API de OpenAPI muestra un ejemplo de una API con un recurso de proxy que se integra con la función de Lambda denominada `SimpleLambda4ProxyResource`.
------
#### [ OpenAPI 3.0 ]
```
{
"openapi": "3.0.0",
"info": {
"version": "2016-09-12T17:50:37Z",
"title": "ProxyIntegrationWithLambda"
},
"paths": {
"/{proxy+}": {
"x-amazon-apigateway-any-method": {
"parameters": [
{
"name": "proxy",
"in": "path",
"required": true,
"schema": {
"type": "string"
}
}
],
"responses": {},
"x-amazon-apigateway-integration": {
"responses": {
"default": {
"statusCode": "200"
}
},
"uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:SimpleLambda4ProxyResource/invocations",
"passthroughBehavior": "when_no_match",
"httpMethod": "POST",
"cacheNamespace": "roq9wj",
"cacheKeyParameters": [
"method.request.path.proxy"
],
"type": "aws_proxy"
}
}
}
},
"servers": [
{
"url": "https://gy415nuibc.execute-api.us-east-1.amazonaws.com/{basePath}",
"variables": {
"basePath": {
"default": "/testStage"
}
}
}
]
}
```
------
#### [ OpenAPI 2.0 ]
```
{
"swagger": "2.0",
"info": {
"version": "2016-09-12T17:50:37Z",
"title": "ProxyIntegrationWithLambda"
},
"host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
"basePath": "/testStage",
"schemes": [
"https"
],
"paths": {
"/{proxy+}": {
"x-amazon-apigateway-any-method": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "proxy",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {},
"x-amazon-apigateway-integration": {
"responses": {
"default": {
"statusCode": "200"
}
},
"uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:SimpleLambda4ProxyResource/invocations",
"passthroughBehavior": "when_no_match",
"httpMethod": "POST",
"cacheNamespace": "roq9wj",
"cacheKeyParameters": [
"method.request.path.proxy"
],
"type": "aws_proxy"
}
}
}
}
}
```
------
Con la integración de proxy de Lambda, API Gateway asigna en tiempo de ejecución una solicitud entrante en el parámetro de entrada `event` de la función de Lambda. La entrada incluye el método de solicitud, la ruta, los encabezados, todos los parámetros de cadena de consulta, todas las cargas, el contexto asociado y todas las variables de etapa definidas. El formato de entrada se explica en [Formato de entrada de una función de Lambda para la integración de proxy](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-input-format). Para que API Gateway asigne la salida de Lambda a respuestas HTTP correctamente, la función de Lambda debe producir el resultado en el formato que se describe en [Formato de salida de una función de Lambda para la integración de proxy](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-output-format).
Con la integración de proxy de Lambda de un recurso de proxy a través del método `ANY`, la función de Lambda del backend actúa como el controlador de eventos de todas las solicitudes a través del recurso de proxy. Por ejemplo, para registrar patrones de tráfico, puede hacer que el dispositivo móvil envíe la información de ubicación del país, la ciudad, la calle y el edificio enviando una solicitud con `/state/city/street/house` en la ruta URL del recurso de proxy. La función de Lambda del backend puede analizar la ruta URL e insertar tuplas de ubicación en una tabla de DynamoDB.
# Configuración de integraciones de Lambda personalizadas en API Gateway
Para mostrar cómo configurar la integración personalizada de Lambda, o sin proxy, creamos una API de API Gateway para exponer el método `GET /greeting?greeter={name}` para invocar una función de Lambda. Utilice uno de los siguientes ejemplos de funciones de Lambda para su API.
Utilice uno de los siguientes ejemplos de funciones de Lambda:
------
#### [ Node.js ]
```
'use strict';
var days = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'];
var times = ['morning', 'afternoon', 'evening', 'night', 'day'];
export const handler = async(event) => {
console.log(event);
// Parse the input for the name, city, time and day property values
let name = event.name === null || event.name === undefined || event.name === "" ? 'you' : event.name;
let city = event.city === undefined ? 'World' : event.city;
let time = times.indexOf(event.time)<0 ? 'day' : event.time;
let day = days.indexOf(event.day)<0 ? null : event.day;
// Generate a greeting
let greeting = 'Good ' + time + ', ' + name + ' of ' + city + '. ';
if (day) greeting += 'Happy ' + day + '!';
// Log the greeting to CloudWatch
console.log('Hello: ', greeting);
// Return a greeting to the caller
return greeting;
};
```
------
#### [ Python ]
```
import json
def lambda_handler(event, context):
print(event)
res = {
"statusCode": 200,
"headers": {
"Content-Type": "*/*"
}
}
if event['greeter'] == "":
res['body'] = "Hello, World"
elif (event['greeter']):
res['body'] = "Hello, " + event['greeter'] + "!"
else:
raise Exception('Missing the required greeter parameter.')
return res
```
------
La función responde con un mensaje de `"Hello, {name}!"` si el valor del parámetro `greeter` es una cadena no vacía. Si el valor `"Hello, World!"` es una cadena vacía, devuelve un mensaje de `greeter`. La función devuelve un mensaje de error de `"Missing the required greeter parameter."` si el parámetro greeter no se ha establecido en la solicitud entrante. Asignamos un nombre a la función `HelloWorld`.
Puede crearla en la consola de Lambda o mediante la AWS CLI. En esta sección, hacemos referencia a esta función mediante los siguientes ARN:
```
arn:aws:lambda:us-east-1:123456789012:function:HelloWorld
```
Una vez establecida la función de Lambda en el backend, proceda a configurar la API.
**Para configurar la integración personalizada de Lambda mediante la AWS CLI.**
1. Utilice el siguiente comando [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) para crear una API privada:
```
aws apigateway create-rest-api --name 'HelloWorld (AWS CLI)'
```
El resultado será similar al siguiente:
```
{
"name": "HelloWorld (AWS CLI)",
"id": "te6si5ach7",
"rootResourceId" : "krznpq9xpg",
"createdDate": 1508461860
}
```
En este ejemplo, se utiliza el `id` de API ( `te6si5ach7`) y el `rootResourceId` (`krznpq9xpg`).
1. Utilice el siguiente comando [create-resource](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-resource.html) para crear un [recurso](https://docs.aws.amazon.com/apigateway/latest/api/API_Resource.html) de `/greeting` de API Gateway:
```
aws apigateway create-resource \
--rest-api-id te6si5ach7 \
--parent-id krznpq9xpg \
--path-part greeting
```
El resultado será similar al siguiente:
```
{
"path": "/greeting",
"pathPart": "greeting",
"id": "2jf6xt",
"parentId": "krznpq9xpg"
}
```
Debe usar el valor `id` del recurso `greeting` (`2jf6xt`) para crear un método en el recurso `/greeting` en el siguiente paso.
1. Utilice el siguiente comando [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) para crear una solicitud de método de API de `GET /greeting?greeter={name}`:
```
aws apigateway put-method --rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method GET \
--authorization-type "NONE" \
--request-parameters method.request.querystring.greeter=false
```
El resultado será similar al siguiente:
```
{
"apiKeyRequired": false,
"httpMethod": "GET",
"authorizationType": "NONE",
"requestParameters": {
"method.request.querystring.greeter": false
}
}
```
Este método de API permite al cliente recibir saludos de la función de Lambda al backend. El parámetro `greeter` es opcional, ya que el backend debería administrar un intermediario anónimo o bien un intermediario identificado.
1. Utilice el siguiente comando [put-method-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method-response.html) para configurar la respuesta `200 OK` a la solicitud de método de `GET /greeting?greeter={name}`:
```
aws apigateway put-method-response \
--rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method GET \
--status-code 200
```
1. Utilice el siguiente comando [put-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration.html) para configurar la integración del método `GET /greeting?greeter={name}` con una función de Lambda denominada `HelloWorld`. Esta función responde a la solicitud con un mensaje de `"Hello, {name}!"`, si se proporciona el parámetro `greeter`, o bien `"Hello, World!"`, si no se ha establecido el parámetro de cadena de consulta.
```
aws apigateway put-integration \
--rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method GET \
--type AWS \
--integration-http-method POST \
--uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:HelloWorld/invocations \
--request-templates '{"application/json":"{\"greeter\":\"$input.params('greeter')\"}"}' \
--credentials arn:aws:iam::123456789012:role/apigAwsProxyRole
```
La plantilla de mapeo proporcionada aquí traslada el parámetro de cadena de consulta `greeter` a la propiedad `greeter` de la carga de JSON. Esto es necesario porque la entrada a una función de Lambda se debe expresar en el cuerpo.
**importante**
Para las integraciones Lambda, debe utilizar el método HTTP de `POST` para la solicitud de integración, según la [especificación de la acción del servicio de Lambda para las invocaciones de funciones](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). El parámetro `uri` es el ARN de la acción que invoca las funciones.
El resultado será similar al siguiente:
```
{
"passthroughBehavior": "WHEN_NO_MATCH",
"cacheKeyParameters": [],
"uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:HelloWorld/invocations",
"httpMethod": "POST",
"requestTemplates": {
"application/json": "{\"greeter\":\"$input.params('greeter')\"}"
},
"cacheNamespace": "krznpq9xpg",
"credentials": "arn:aws:iam::123456789012:role/apigAwsProxyRole",
"type": "AWS"
}
```
El rol de IAM de `apigAwsProxyRole` debe tener políticas que permiten al servicio `apigateway` invocar funciones de Lambda. En lugar de proporcionar un rol de IAM para `credentials`, puede llamar al comando [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) para agregar permisos basados en recursos. De este modo es como la consola de API Gateway agrega estos permisos.
1. Utilice el siguiente comando [put-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration-response.html) para configurar la respuesta de integración y pasar el resultado de la función de Lambda al cliente como respuesta del método `200 OK`:
```
aws apigateway put-integration-response \
--rest-api-id te6si5ach7 \
--resource-id 2jf6xt \
--http-method GET \
--status-code 200 \
--selection-pattern ""
```
Si se establece el patrón de selección en una cadena vacía, la respuesta `200 OK` es la opción predeterminada.
El resultado será similar al siguiente:
```
{
"selectionPattern": "",
"statusCode": "200"
}
```
1. Utilice el siguiente comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-deployment.html) para implementar la API en una etapa `test`:
```
aws apigateway create-deployment \
--rest-api-id te6si5ach7 \
--stage-name test
```
1. Pruebe la API mediante el siguiente comando cURL en un terminal:
```
curl -X GET 'https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/greeting?greeter=me' \
-H 'authorization: AWS4-HMAC-SHA256 Credential={access_key}/20171020/us-west-2/execute-api/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=f327...5751'
```
# Configurar la invocación asíncrona de la función de Lambda de backend
En la integración de Lambda no de proxy (personalizada), se invoca la función de Lambda de backend, de forma síncrona y de forma predeterminada. Este es el comportamiento deseado para la mayoría de operaciones de API de REST. Algunas aplicaciones, sin embargo, requieren que el trabajo se realice de forma asíncrona (como una operación por lotes o una operación de latencia), normalmente por un componente backend independiente. En este caso, la función de Lambda del backend se invoca de forma asíncrona y el método de la API REST de front-end no devuelve el resultado.
Puede configurar la función de Lambda para una integración de Lambda que no sea proxy para invocarla de forma asíncrona especificando `'Event'` como el [tipo de invocación de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html). Esto se realiza de la siguiente manera:
## Configurar la invocación asíncrona de Lambda en la consola de API Gateway
Para que todas las invocaciones sean asincrónicas:
+ En **Solicitud de integración**, añada un encabezado `X-Amz-Invocation-Type` con un valor estático de `'Event'`.
Para que los clientes decidan si las invocaciones son asincrónicas o sincrónicas:
1. En **Solicitud de método**, añada un encabezado `InvocationType`.
1. En **Solicitud de integración**, añada un encabezado `X-Amz-Invocation-Type` con una expresión de mapeo de `method.request.header.InvocationType`.
1. Los clientes pueden incluir el encabezado `InvocationType: Event` en solicitudes de API para invocaciones asincrónicas o `InvocationType: RequestResponse` para invocaciones sincrónicas.
## Configurar la invocación asíncrona de Lambda mediante OpenAPI
Para que todas las invocaciones sean asincrónicas:
+ Agregue el encabezado `X-Amz-Invocation-Type` a la sección **x-amazon-apigateway-integration**.
```
"x-amazon-apigateway-integration" : {
"type" : "aws",
"httpMethod" : "POST",
"uri" : "arn:aws:apigateway:us-east-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-2:123456789012:function:my-function/invocations",
"responses" : {
"default" : {
"statusCode" : "200"
}
},
"requestParameters" : {
"integration.request.header.X-Amz-Invocation-Type" : "'Event'"
},
"passthroughBehavior" : "when_no_match",
"contentHandling" : "CONVERT_TO_TEXT"
}
```
Para que los clientes decidan si las invocaciones son asincrónicas o sincrónicas:
1. Agregue el siguiente encabezado en cualquier [objeto Path Item de OpenAPI](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#pathItemObject).
```
"parameters" : [ {
"name" : "InvocationType",
"in" : "header",
"schema" : {
"type" : "string"
}
} ]
```
1. Agregue el encabezado `X-Amz-Invocation-Type` a la sección **x-amazon-apigateway-integration**.
```
"x-amazon-apigateway-integration" : {
"type" : "aws",
"httpMethod" : "POST",
"uri" : "arn:aws:apigateway:us-east-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-2:123456789012:function:my-function/invocations",
"responses" : {
"default" : {
"statusCode" : "200"
}
},
"requestParameters" : {
"integration.request.header.X-Amz-Invocation-Type" : "method.request.header.InvocationType"
},
"passthroughBehavior" : "when_no_match",
"contentHandling" : "CONVERT_TO_TEXT"
}
```
1. Los clientes pueden incluir el encabezado `InvocationType: Event` en solicitudes de API para invocaciones asincrónicas o `InvocationType: RequestResponse` para invocaciones sincrónicas.
## Configuración de la invocación asíncrona de Lambda mediante CloudFormation
Las siguientes plantillas de CloudFormation muestran cómo configurar `AWS::ApiGateway::Method` para las invocaciones asíncronas.
Para que todas las invocaciones sean asincrónicas:
```
AsyncMethodGet:
Type: 'AWS::ApiGateway::Method'
Properties:
RestApiId: !Ref Api
ResourceId: !Ref AsyncResource
HttpMethod: GET
ApiKeyRequired: false
AuthorizationType: NONE
Integration:
Type: AWS
RequestParameters:
integration.request.header.X-Amz-Invocation-Type: "'Event'"
IntegrationResponses:
- StatusCode: '200'
IntegrationHttpMethod: POST
Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${myfunction.Arn}$/invocations
MethodResponses:
- StatusCode: '200'
```
Para que los clientes decidan si las invocaciones son asincrónicas o sincrónicas:
```
AsyncMethodGet:
Type: 'AWS::ApiGateway::Method'
Properties:
RestApiId: !Ref Api
ResourceId: !Ref AsyncResource
HttpMethod: GET
ApiKeyRequired: false
AuthorizationType: NONE
RequestParameters:
method.request.header.InvocationType: false
Integration:
Type: AWS
RequestParameters:
integration.request.header.X-Amz-Invocation-Type: method.request.header.InvocationType
IntegrationResponses:
- StatusCode: '200'
IntegrationHttpMethod: POST
Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${myfunction.Arn}$/invocations
MethodResponses:
- StatusCode: '200'
```
Los clientes pueden incluir el encabezado `InvocationType: Event` en solicitudes de API para invocaciones asincrónicas o `InvocationType: RequestResponse` para invocaciones sincrónicas.
# Gestionar los errores de Lambda en API Gateway
Para las integraciones de Lambda personalizadas, debe asignar los errores devueltos por Lambda en la respuesta de integración a las respuestas de error de HTTP estándar para sus clientes. De lo contrario, los errores de Lambda se devuelven como respuestas `200 OK` de forma predeterminada y el resultado no es intuitivo para los usuarios de la API.
Hay dos tipos de errores que Lambda puede devolver: errores estándar y errores personalizados. En la API, debe tratarlos de forma diferente.
Con la integración de proxy de Lambda, Lambda debe devolver una salida con el siguiente formato:
```
{
"isBase64Encoded" : "boolean",
"statusCode": "number",
"headers": { ... },
"body": "JSON string"
}
```
En esta salida, `statusCode` es normalmente `4XX` para un error del cliente y `5XX` para un error del servidor. API Gateway trata estos errores asignando el error de Lambda a una respuesta de error HTTP, de acuerdo con el especificad `statusCode`. Para que API Gateway transmita el tipo de error (por ejemplo, `InvalidParameterException`), como parte de la respuesta al cliente, la función de Lambda debe incluir un encabezado (por ejemplo, `"X-Amzn-ErrorType":"InvalidParameterException"`) en la propiedad `headers`.
**Topics**
+ [Gestionar los errores de Lambda estándares en API Gateway.](#handle-standard-errors-in-lambda-integration)
+ [Gestionar los errores de Lambda personalizados en API Gateway](#handle-custom-errors-in-lambda-integration)
## Gestionar los errores de Lambda estándares en API Gateway.
Un error estándar de AWS Lambda tiene el siguiente formato:
```
{
"errorMessage": "string",
"errorType": "string",
"stackTrace": [
"string",
...
]
}
```
Aquí, `errorMessage` es una expresión de cadena del error. `errorType` es un tipo de error o excepción dependiente del lenguaje. `stackTrace` es una lista de expresiones de cadena que indican la pila de rastreo que conduce a la aparición del error.
Por ejemplo, observe la siguiente función de Lambda en JavaScript (Node.js).
```
export const handler = function(event, context, callback) {
callback(new Error("Malformed input ..."));
};
```
Esta función devuelve el siguiente error de Lambda estándar, que contiene `Malformed input ...` como el mensaje de error:
```
{
"errorMessage": "Malformed input ...",
"errorType": "Error",
"stackTrace": [
"export const handler (/var/task/index.js:3:14)"
]
}
```
Asimismo, considere la siguiente función de Lambda de Python, que produce una `Exception` con el mismo mensaje de error `Malformed input ...`.
```
def lambda_handler(event, context):
raise Exception('Malformed input ...')
```
Esta función devuelve el siguiente error de Lambda estándar:
```
{
"stackTrace": [
[
"/var/task/lambda_function.py",
3,
"lambda_handler",
"raise Exception('Malformed input ...')"
]
],
"errorType": "Exception",
"errorMessage": "Malformed input ..."
}
```
Tenga en cuenta que los valores de las propiedades `errorType` y `stackTrace` dependen del lenguaje. El error estándar también se aplica a cualquier objeto de error que sea una extensión del objeto `Error` o una subclase de la clase `Exception`.
Para asignar el error de Lambda estándar a una respuesta del método, primero debe decidir cuál es el código de estado HTTP para un error de Lambda determinado. Seguidamente, debe establecer un patrón de expresiones regulares en la propiedad `[selectionPattern](https://docs.aws.amazon.com/apigateway/latest/api/API_IntegrationResponse.html#selectionPattern)` del recurso [IntegrationResponse](https://docs.aws.amazon.com/apigateway/latest/api/API_IntegrationResponse.html) asociado con el código de estado HTTP especificado. En la consola de API Gateway, este `selectionPattern` se denomina **Expresión regular de error de Lambda** en la sección **Respuesta de integración**, debajo de cada respuesta de integración.
**nota**
API Gateway utiliza expresiones regulares de estilo de patrón de Java para el mapeo de respuesta. Para obtener más información, consulte [Pattern (Patrón)](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html) en la documentación de Oracle.
Por ejemplo, use el siguiente comando [put-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration-response.html) para configurar una nueva expresión `selectionPattern`:
```
aws apigateway put-integration-response --rest-api-id z0vprf0mdh --resource-id x3o5ih --http-method GET --status-code 400 --selection-pattern "Malformed.*" --region us-west-2
```
Asegúrese de configurar también el código de error correspondiente (`400`) en la [respuesta del método](api-gateway-method-settings-method-response.md#setup-method-response-status-code). De lo contrario, API Gateway produce una respuesta de error de configuración no válida en tiempo de ejecución.
**nota**
En el tiempo de ejecución, API Gateway coteja el `errorMessage` de error de Lambda con el patrón de la expresión regular en la propiedad `selectionPattern`. Si hay una coincidencia, API Gateway devuelve el error de Lambda como una respuesta HTTP del código de estado HTTP correspondiente. Si no hay ninguna coincidencia, API Gateway devuelve el error como una respuesta predeterminada o produce una excepción de configuración no válida si no se ha configurado una respuesta predeterminada.
Configurar el valor `selectionPattern` a `.*` para una determinada respuesta equivale a restablecer esta respuesta como la predeterminada. Esto se debe a que un patrón de solicitud de este tipo coincidirá con todos los mensajes de error, incluidos los nulos, es decir, cualquier mensaje de error no especificado. El mapeo resultante anula al predeterminado. Si utiliza `.+` como patrón de selección para filtrar respuestas, tenga en cuenta que puede que no coincida con una respuesta que contenga un carácter de nueva línea ('`\n`).
Para actualizar un valor de `selectionPattern` existente mediante la API REST de la AWS CLI, llame a la operación [update-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-integration-response.html) para reemplazar el valor de ruta de `/selectionPattern` por la expresión regular especificada con el patrón `Malformed*`.
Para establecer la expresión `selectionPattern` con la consola de API Gateway, escriba la expresión en el cuadro de texto **Expresión regular de error de Lambda** cuando configure o actualice una respuesta de integración de un código de estado HTTP especificado.
## Gestionar los errores de Lambda personalizados en API Gateway
En lugar del error estándar descrito en la sección anterior, AWS Lambda le permite devolver un objeto de error personalizado como una cadena JSON. El error puede ser cualquier objeto JSON válido. Por ejemplo, la siguiente función de Lambda en JavaScript (Node.js) devuelve un error personalizado:
```
export const handler = (event, context, callback) => {
...
// Error caught here:
var myErrorObj = {
errorType : "InternalServerError",
httpStatus : 500,
requestId : context.awsRequestId,
trace : {
"function": "abc()",
"line": 123,
"file": "abc.js"
}
}
callback(JSON.stringify(myErrorObj));
};
```
Debe activar el objeto `myErrorObj` en una cadena JSON antes de llamar a `callback` para salir de la función. De lo contrario, `myErrorObj` se devuelve como una cadena de `"[object Object]"`. Cuando un método de la API está integrado con la función API Gateway anterior, Lambda recibe una respuesta de integración con la siguiente carga:
```
{
"errorMessage": "{\"errorType\":\"InternalServerError\",\"httpStatus\":500,\"requestId\":\"e5849002-39a0-11e7-a419-5bb5807c9fb2\",\"trace\":{\"function\":\"abc()\",\"line\":123,\"file\":\"abc.js\"}}"
}
```
Al igual que con cualquier respuesta de integración, puede transferir esta respuesta de error tal como está a la respuesta del método. O puede usar una plantilla de mapeo para transformar la carga en un formato diferente. Considere, por ejemplo, la siguiente plantilla de asignación de cuerpo para una respuesta de método del código de estado `500`:
```
{
errorMessage: $input.path('$.errorMessage');
}
```
Esta plantilla traduce el cuerpo de respuesta de la integración que contiene la cadena JSON del error personalizado en el siguiente cuerpo de respuesta del método. Este cuerpo de respuesta del método contiene el objeto JSON del error personalizado:
```
{
"errorMessage" : {
errorType : "InternalServerError",
httpStatus : 500,
requestId : context.awsRequestId,
trace : {
"function": "abc()",
"line": 123,
"file": "abc.js"
}
}
};
```
En función de los requisitos de la API, es posible que tenga que pasar algunas o todas las propiedades de errores personalizados como parámetros de encabezado de la respuesta del método. Para ello, puede aplicar asignaciones de errores personalizados desde el cuerpo de respuesta de integración a los encabezados de respuesta del método.
Por ejemplo, la siguiente extensión de OpenAPI define una asignación desde las propiedades `errorMessage.errorType`, `errorMessage.httpStatus`, `errorMessage.trace.function` y `errorMessage.trace` a `error_type`, `error_status`, `error_trace_function` y `error_trace`, respectivamente.
```
"x-amazon-apigateway-integration": {
"responses": {
"default": {
"statusCode": "200",
"responseParameters": {
"method.response.header.error_trace_function": "integration.response.body.errorMessage.trace.function",
"method.response.header.error_status": "integration.response.body.errorMessage.httpStatus",
"method.response.header.error_type": "integration.response.body.errorMessage.errorType",
"method.response.header.error_trace": "integration.response.body.errorMessage.trace"
},
...
}
}
}
```
En tiempo de ejecución, API Gateway deserializa el parámetro `integration.response.body` cuando realiza mapeos de encabezado. Sin embargo, esta deserialización se aplica únicamente a los mapeos de cuerpo a encabezado para respuestas de errores personalizados de Lambda y no se aplica a los mapeos de cuerpo a cuerpo que utilizan `$input.body`. Con estas asignaciones de cuerpo a encabezado de errores personalizados, el cliente recibe los siguientes encabezados como parte de la respuesta del método, siempre que los encabezados `error_status`, `error_trace`, `error_trace_function` y `error_type` estén declarados en la solicitud del método.
```
"error_status":"500",
"error_trace":"{\"function\":\"abc()\",\"line\":123,\"file\":\"abc.js\"}",
"error_trace_function":"abc()",
"error_type":"InternalServerError"
```
La propiedad `errorMessage.trace` del cuerpo de respuesta de integración es una propiedad compleja. Se asigna al encabezado `error_trace` como una cadena JSON.