# Optimización del rendimiento de las API de REST Después de que haya hecho que su API esté disponible para ser llamada, es posible que se dé cuenta de que necesita optimizarse para mejorar la capacidad de respuesta. API Gateway proporciona algunas estrategias para optimizar su API, como el almacenamiento en caché de respuesta y la compresión de carga útil. En esta sección, puede aprender a habilitar estas capacidades. **Topics** + [Configuración de caché para las API de REST en API Gateway](api-gateway-caching.md) + [Compresión de la carga útil para las API de REST en API Gateway](api-gateway-gzip-compression-decompression.md) # Configuración de caché para las API de REST en API Gateway Puede habilitar el almacenamiento en caché de la API en API Gateway para almacenar en caché las respuestas del punto de conexión. Con el almacenamiento en caché, puede reducir el número de llamadas realizadas al punto de conexión y mejorar también la latencia de las solicitudes a la API. Cuando habilita el almacenamiento en caché para una etapa, API Gateway almacena en caché las respuestas del punto de conexión durante el período de tiempo de vida (TTL) especificado, en segundos. A continuación, API Gateway responde a la solicitud buscando la respuesta del punto de conexión en la caché en lugar de realizar una solicitud al punto de conexión. El valor de TTL predeterminado para el almacenamiento en caché de la API es de 300 segundos. El valor de TTL máximo es de 3600 segundos. TTL = 0 significa que el almacenamiento en caché está deshabilitado. **nota** El almacenamiento en caché es el mejor esfuerzo. Puede utilizar las métricas `CacheHitCount` y `CacheMissCount` en Amazon CloudWatch para monitorear las solicitudes que API Gateway atiende desde la caché de la API. El tamaño máximo de una respuesta que se puede almacenar en la caché es 1048576 bytes. El cifrado de datos en la caché puede aumentar el tamaño de la respuesta cuando se almacena en la caché. Se trata de un servicio compatible con HIPAA. Para obtener más información acerca de AWS, la ley de responsabilidad y portabilidad de seguros médicos de Estados Unidos de 1996 (HIPAA) y el uso de los servicios de AWS para procesar, almacenar y transmitir información sanitaria protegida (PHI), consulte [Información general sobre la HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). **importante** Al habilitar el almacenamiento en caché para una etapa, solo los métodos `GET` tienen el almacenamiento en caché habilitado de forma predeterminada. Esto ayuda a garantizar la seguridad y la disponibilidad de la API. Puede habilitar el almacenamiento en caché para otros métodos [invalidando la configuración del método](#override-api-gateway-stage-cache-for-method-cache). **importante** El almacenamiento en caché se cobra por hora en función del tamaño de la memoria caché que seleccione. El almacenamiento en memoria caché no está disponible para la capa gratuita de AWS. Para obtener más información, consulte [Precio de API Gateway](https://aws.amazon.com/api-gateway/pricing/). ## Activar almacenamiento en caché de Amazon API Gateway En API Gateway, puede habilitar el almacenamiento en caché para una etapa específica. Al habilitar el almacenamiento en caché, debe elegir una capacidad de caché. En general, una capacidad mayor ofrece un mejor desempeño, pero también cuesta más. Para conocer los tamaños de la memoria caché admitidos, consulte [cacheClusterSize](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateStage.html#apigw-CreateStage-request-cacheClusterSize) en la *referencia de API de API Gateway*. API Gateway permite el almacenamiento en caché creando una instancia de caché dedicada. Este proceso puede tardar hasta cuatro minutos. API Gateway cambia la capacidad de almacenamiento en caché eliminando al instancia de caché y creando una nueva con una capacidad modificada. Todos los datos almacenados en la memoria caché existente se eliminan. **nota** La capacidad de la caché afecta la CPU, la memoria y el ancho de banda de red de la instancia de caché. Como resultado, la capacidad de la caché puede afectar el rendimiento de dicha caché. API Gateway recomienda ejecutar una prueba de carga de 10 minutos para comprobar que la capacidad de la caché sea adecuada para la carga de trabajo. Asegúrese de que durante la prueba de carga el tráfico refleje el tráfico de producción. Por ejemplo, incluya aumento gradual, tráfico constante y picos de tráfico. La prueba de carga debe incluir respuestas que se puedan entregar desde la caché, así como respuestas individuales que agreguen elementos a dicha caché. Monitoree las métricas de latencia, 4xx, 5xx, métricas de aciertos y errores de la caché durante la prueba de carga. Ajuste la capacidad de la caché según sea necesario en función de estas métricas. Para obtener más información sobre las pruebas de carga, consulte [¿Cómo selecciono la mejor capacidad de memoria caché de API Gateway para evitar alcanzar un límite de velocidad?](https://repost.aws/knowledge-center/api-gateway-cache-capacity). ------ #### [ Consola de administración de AWS ] En la consola de API Gateway, se configura el almacenamiento en caché en la página **Etapas**. Debe aprovisionar la caché de etapas y especificar una configuración de caché predeterminada en el nivel de método. Si activa la caché en el nivel de método predeterminada, la caché en el nivel de método se activa para todos los métodos `GET` de la etapa, a menos que ese método tenga una invalidación de método. Cualquier método `GET` adicional que implemente en la etapa tendrá una caché en el nivel de método. Para configurar los ajustes de almacenamiento en caché en el nivel de método para métodos específicos de la etapa, puede utilizar invalidaciones de método. Para obtener más información acerca de las invalidaciones de métodos, consulte [Invalidación del almacenamiento en caché en el nivel de etapa de API Gateway para el almacenamiento en caché en el nivel de método](#override-api-gateway-stage-cache-for-method-cache). **Para configurar el almacenamiento en caché de la API para una determinada etapa:** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Elija **Stages (Etapas)**. 1. En la lista **Stages (Etapas)** de la API, elija la etapa. 1. En la sección **Detalles de la etapa**, elija **Editar**. 1. En **Configuración adicional**, para **Configuración de caché**, active **Aprovisionar caché de API**. Esto proporciona un clúster de caché para la etapa. 1. Para activar el almacenamiento en caché para la etapa, active **Almacenamiento en caché de nivel de método predeterminado**. Esto activa el almacenamiento en caché en el nivel de método para todos los métodos `GET` de la etapa. Cualquier método `GET` adicional que implemente en esta etapa tendrá una caché en el nivel de método. **nota** Si ya tiene una configuración para una caché en el nivel de método, el cambio de la configuración predeterminada de almacenamiento en caché en el nivel de método no afectará a esa configuración existente. ![\[Active el aprovisionamiento caché de API y el almacenamiento en caché de nivel de método predeterminado.\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/api-caching-stage-flow.png) 1. Seleccione **Save changes (Guardar cambios)**. ------ #### [ AWS CLI ] El siguiente comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) permite actualizar una etapa para aprovisionar una caché y activar el almacenamiento en caché de nivel de método para todos los métodos `GET` de la etapa: ``` aws apigateway update-stage \ --rest-api-id a1b2c3 \ --stage-name 'prod' \ --patch-operations file://patch.json ``` El contenido de `patch.json` es el siguiente: ``` [ { "op": "replace", "path": "/cacheClusterEnabled", "value": "true" }, { "op": "replace", "path": "/cacheClusterSize", "value": "0.5" }, { "op": "replace", "path": "/*/*/caching/enabled", "value": "true" } ] ``` **nota** Si ya tiene una configuración para una caché en el nivel de método, el cambio de la configuración predeterminada de almacenamiento en caché en el nivel de método no afectará a esa configuración existente. ------ **nota** La creación o eliminación de una memoria caché tarda unos cuatro minutos en completarse en API Gateway. Cuando se crea una caché, el valor de **Clúster de caché** cambia de `Create in progress` a `Active`. Cuando se completa la eliminación de la caché, el valor de **Clúster de caché** cambia de `Delete in progress` a `Inactive`. Al activar el almacenamiento en caché en el nivel de método para todos los métodos de la etapa, el valor de **Almacenamiento en caché en el nivel de método predeterminado** cambia a `Active`. Si desactiva el almacenamiento en caché en el nivel de método para todos los métodos de la etapa, el valor de **Almacenamiento en caché en el nivel de método predeterminado** cambia a `Inactive`. Si ya tiene una configuración para una caché en el nivel de método, el cambio del estado de la caché no afecta a esa configuración. Cuando se habilita el almacenamiento en caché en **Configuración de caché** de la etapa, solo se almacenan en caché los métodos `GET`. Para garantizar la seguridad y la disponibilidad de la API, le recomendamos que no cambie esta configuración. Sin embargo, puede habilitar el almacenamiento en caché para otros métodos [invalidando la configuración del método](#override-api-gateway-stage-cache-for-method-cache). Si desea comprobar si el almacenamiento en caché funciona según lo previsto, tiene dos opciones generales: + Revise las métricas de CloudWatch de **CacheHitCount** y **CacheMissCount** para la API y la etapa. + Inserte una marca de tiempo en la respuesta. **nota** No utilice el encabezado `X-Cache` de la respuesta de CloudFront para determinar si la API se está sirviendo desde la instancia de caché de API Gateway. ## Invalidación del almacenamiento en caché en el nivel de etapa de API Gateway para el almacenamiento en caché en el nivel de método Puede invalidar la configuración de caché en el nivel de etapa activando o desactivando el almacenamiento en caché para un método específico. Puede también modificar el periodo de TTL o activar o desactivar el cifrado para respuestas almacenadas en caché. Si prevé que un método que está almacenando en caché va a recibir información confidencial en sus respuestas, cifre los datos de la caché. Es probable que deba hacerlo para asegurar el cumplimiento con diversos marcos normativos. Para obtener más información, consulte [Controles de Amazon API Gateway](https://docs.aws.amazon.com/securityhub/latest/userguide/apigateway-controls.html) en la *Guía del usuario de AWS Security Hub*. ------ #### [ Consola de administración de AWS ] Si cambia la configuración predeterminada del almacenamiento en caché en el nivel de método en **Detalles de la etapa**, la configuración de la caché en el nivel de método que tiene invalidaciones no se verá afectada. Si prevé que un método que almacena en caché va a recibir información confidencial en sus respuestas, en **Cache Settings (Configuración de caché)**, elija **Encrypt cache data (Cifrar datos de caché)**. **Para configurar los métodos individuales de almacenamiento en caché de la API para utilizar la consola:** 1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Elija la API. 1. Elija **Stages (Etapas)**. 1. En la lista **Stages (Etapas)** de la API, expanda la etapa y elija un método en la API. 1. En la sección **Invalidaciones de métodos**, elija **Editar**. 1. En la sección **Configuración del método**, active o desactive **Habilitar la caché de métodos** o personalice cualquier otra opción que desee. **nota** El almacenamiento en caché no está activo hasta que aprovisione un clúster de caché para la etapa. 1. Seleccione **Save**. ------ #### [ AWS CLI ] El siguiente comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) permite desactivar la caché solo para el método `GET /pets`: ``` aws apigateway update-stage / --rest-api-id a1b2c3 / --stage-name 'prod' / --patch-operations file://patch.json ``` El contenido de `patch.json` es el siguiente: ``` [{ "op": "replace", "path": "/~1pets/GET/caching/enabled", "value": "false" }] ``` ------ ## Usar parámetros de método o integración como claves de caché para indexar las respuestas almacenadas en caché Puede usar un parámetro de método o integración como claves de caché para indexar las respuestas almacenadas en caché. Esto incluye encabezados personalizados, rutas de URL o cadenas de consulta. Puede especificar alguno de estos parámetros o todos ellos como la clave de caché, pero debe especificar al menos un valor. Cuando tiene una clave de caché, API Gateway almacena en caché las respuestas de cada valor de clave de forma independiente, incluso cuando la clave de caché no está presente. **nota** Las claves de caché son necesarias cuando se configura el almacenamiento en caché en un recurso. Suponga, por ejemplo, que tiene una solicitud con el siguiente formato: ``` GET /users?type=... HTTP/1.1 host: example.com ... ``` En esta solicitud, `type` puede tomar un valor de `admin` o `regular`. Si incluye el parámetro `type` como parte de la clave de caché, las respuestas de `GET /users?type=admin` se almacenan en caché por separado de las de `GET /users?type=regular`. Cuando una solicitud de método o integración toma más de un parámetro, puede elegir algunos o todos los parámetros para crear la clave de caché. Por ejemplo, puede incluir solamente el parámetro `type` en la clave de caché para la siguiente solicitud, realizada en el orden indicado dentro de un período de TTL: ``` GET /users?type=admin&department=A HTTP/1.1 host: example.com ... ``` La respuesta de esta solicitud se almacena en caché y se utiliza para servir la siguiente solicitud: ``` GET /users?type=admin&department=B HTTP/1.1 host: example.com ... ``` ------ #### [ Consola de administración de AWS ] Para incluir un parámetro de solicitud de método o integración como parte de una clave de caché en la consola de API Gateway, seleccione **Caching** después de agregar el parámetro. ![\[Incluir parámetros de método o integración como claves de caché para indexar las respuestas almacenadas en caché\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/api-caching-including-parameter-as-cache-key-new-console.png) ------ #### [ AWS CLI ] El siguiente comando [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) permite crear un método `GET` y requiere el parámetro de cadena de consulta `type`: ``` aws apigateway put-method / --rest-api-id a1b2c3 / --resource-id aaa111 / --http-method GET / --authorization-type "NONE" / --request-parameters "method.request.querystring.type=true" ``` El siguiente comando [put-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration.html) permite crear una integración para el método `GET` con un punto de conexión HTTP y especifica que API Gateway almacene en caché el parámetro de solicitud del método `type`: ``` aws apigateway put-integration / --rest-api-id a1b2c3 / --resource-id aaa111 / --http-method GET / --type HTTP / --integration-http-method GET / --uri 'https://example.com' / --cache-key-parameters "method.request.querystring.type" ``` Para especificar que API Gateway almacene en caché un parámetro de solicitud de integración, utilice `integration.request.location.name` como parámetro de clave de caché. ------ ## Vaciar la caché de etapa de API en API Gateway Cuando el almacenamiento en caché de la API está habilitado, puede vaciar la caché de etapas de API para asegurarse de que los clientes de la API obtengan las respuestas más recientes de los puntos de conexión de integración. ------ #### [ Consola de administración de AWS ] **Vaciado de la caché de etapas de la API** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Elija una API que tenga una etapa con una caché. 1. En el panel de navegación principal, elija **Etapas** y, a continuación, elija una etapa con caché. 1. Elija el menú **Acciones de etapa** y, a continuación, seleccione **Vaciar la caché de etapas**. ------ #### [ AWS CLI ] El siguiente comando [flush-stage-cache](https://docs.aws.amazon.com/cli/latest/reference/apigateway/flush-stage-cache.html) permite vaciar la caché de etapas: ``` aws apigateway flush-stage-cache \ --rest-api-id a1b2c3 \ --stage-name prod ``` ------ **nota** Después de que la caché se vacía, las respuestas se atienden desde el punto de conexión de integración hasta que se vuelva a crear la caché. Durante este período, el número de solicitudes enviadas al punto de conexión de integración puede aumentar. Esto podría aumentar temporalmente la latencia total de la API. ## Invalidar una entrada de caché de API Gateway Un cliente de la API puede invalidar una entrada de caché existente y volver a cargarla desde el punto de conexión de integración para las distintas solicitudes. El cliente debe enviar una solicitud que contenga el encabezado `Cache-Control: max-age=0`. El cliente recibe la respuesta directamente del punto de conexión de integración en lugar de la caché, siempre que el cliente esté autorizado para ello. Esto sustituye la entrada de caché existente por la nueva respuesta, que se obtiene del punto de conexión de integración. Para conceder permiso a un cliente, asocie una política con el siguiente formato a una función de ejecución de IAM del usuario. **nota** No se admite la invalidación de la memoria caché entre cuentas. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:InvalidateCache" ], "Resource": [ "arn:aws:execute-api:us-east-1:111111111111:api-id/stage-name/GET/resource-path-specifier" ] } ] } ``` ------ Esta política permite al servicio de ejecución de API Gateway invalidar la caché para las solicitudes en el recurso o recursos especificados. Para especificar un grupo de recursos de destino, utilice el carácter comodín (\$1) para `account-id`, `api-id` y otras entradas en el valor de ARN de `Resource`. Para obtener más información sobre cómo establecer permisos para el servicio de ejecución de API Gateway, consulte [Control del acceso a una API de REST con permisos de IAM](permissions.md). Si no impone una política `InvalidateCache` (o selecciona la casilla de verificación **Require authorization (Solicitar autorización)**), cualquier cliente puede invalidar la caché de la API. Si la mayoría o todos los clientes invalidan la caché de la API, esto podría aumentar considerablemente la latencia de la API. Cuando la política está implantada, se habilita el almacenamiento en caché y se requiere autorización. Para especificar el modo en que API Gateway gestiona las solicitudes no autorizadas, seleccione una de las opciones siguientes: **Error de la solicitud con código de estado 403** API Gateway devuelve una respuesta `403 Unauthorized`. Para establecer esta opción mediante la API, use `FAIL_WITH_403`. **Omisión del encabezado de control de caché; adición de una advertencia en el encabezado de la respuesta** API Gateway procesa la solicitud y agrega un encabezado de advertencia en la respuesta. Para establecer esta opción mediante la API, use `SUCCEED_WITH_RESPONSE_HEADER`. **Omisión del encabezado de control de caché** API Gateway procesa la solicitud y no agrega un encabezado de advertencia en la respuesta. Para establecer esta opción mediante la API, use `SUCCEED_WITHOUT_RESPONSE_HEADER`. Puede establecer el comportamiento de gestión de las solicitudes no autorizadas con la consola de API Gateway o con AWS CLI. ------ #### [ Consola de administración de AWS ] **Para especificar cómo se gestionan las solicitudes no autorizadas** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Elija una API que tenga una etapa con una caché. 1. En el panel de navegación principal, elija **Etapas** y, a continuación, elija una etapa con caché. 1. Para ver los **Detalles de la etapa**, seleccione **Editar**. 1. Seleccione una opción para **Gestión de solicitudes no autorizadas**. 1. Elija **Continuar**. 1. Revise los cambios y elija **Guardar cambios**. ------ #### [ AWS CLI ] El siguiente comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) actualiza una etapa para gestionar las solicitudes no autorizadas devolviendo un error con código de estado 403 para la solicitud: ``` aws apigateway update-stage / --rest-api-id a1b2c3 / --stage-name 'prod' / --patch-operations 'op=replace,path=/*/*/caching/unauthorizedCacheControlHeaderStrategy,value="FAIL_WITH_403"' ``` ------ ## Ejemplo de CloudFormation de una etapa con caché La siguiente plantilla de CloudFormation crea una API de ejemplo, aprovisiona una caché de `0.5` GB para la etapa `Prod` y activa el almacenamiento en caché de nivel de método para todos los métodos `GET`. **importante** El almacenamiento en caché se cobra por hora en función del tamaño de la memoria caché que seleccione. El almacenamiento en memoria caché no está disponible para la capa gratuita de AWS. Para obtener más información, consulte [Precio de API Gateway](https://aws.amazon.com/api-gateway/pricing/). ### Plantilla de CloudFormation de ejemplo ``` AWSTemplateFormatVersion: 2010-09-09 Resources: Api: Type: 'AWS::ApiGateway::RestApi' Properties: Name: cache-example PetsResource: Type: 'AWS::ApiGateway::Resource' Properties: RestApiId: !Ref Api ParentId: !GetAtt Api.RootResourceId PathPart: 'pets' PetsMethodGet: Type: 'AWS::ApiGateway::Method' Properties: RestApiId: !Ref Api ResourceId: !Ref PetsResource HttpMethod: GET ApiKeyRequired: true AuthorizationType: NONE Integration: Type: HTTP_PROXY IntegrationHttpMethod: GET Uri: http://petstore-demo-endpoint.execute-api.com/petstore/pets/ ApiDeployment: Type: 'AWS::ApiGateway::Deployment' DependsOn: - PetsMethodGet Properties: RestApiId: !Ref Api ApiStage: Type: 'AWS::ApiGateway::Stage' Properties: StageName: Prod Description: Prod Stage with a cache RestApiId: !Ref Api DeploymentId: !Ref ApiDeployment CacheClusterEnabled: True CacheClusterSize: 0.5 MethodSettings: - ResourcePath: /* HttpMethod: '*' CachingEnabled: True ``` # Compresión de la carga útil para las API de REST en API Gateway API Gateway permite que el cliente llame a la API con cargas comprimidas utilizando una de las [codificaciones de contenido compatibles](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). De forma predeterminada, API Gateway admite la descompresión de la carga de solicitud del método. Sin embargo, debe configurar la API para que se habilite la compresión de la carga de respuesta del método. Para habilitar la compresión de una [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html), establezca la propiedad [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize) en un número entero que no sea negativo y esté comprendido entre 0 y 10485760 (10 M bytes) cuando cree la API o después de crearla. Para deshabilitar la compresión de la API, establezca `minimumCompressionSize` en null o elimínelo por completo. Puede habilitar o desactivar la compresión de una API mediante la consola de API Gateway, la AWS CLI o la API REST de API Gateway. Si desea que la compresión se aplique en una carga de cualquier tamaño, establezca el valor `minimumCompressionSize` en cero. Sin embargo, es posible que los datos pequeños, al comprimirse, aumenten de tamaño. Además, la compresión de API Gateway y la descompresión en el cliente podrían aumentar la latencia general y requerir más tiempo de procesamiento. Debe ejecutar los casos de prueba en la API para determinar un valor óptimo. El cliente puede enviar una solicitud de API con una carga comprimida y un encabezado `Content-Encoding` adecuado para que API Gateway descomprima y aplique las plantillas de asignaciones correspondientes antes de pasar la solicitud al punto de conexión de integración. Una vez que la compresión está habilitada y la API está implementada, el cliente puede recibir una respuesta de API con una carga comprimida si especifica un encabezado `Accept-Encoding` adecuado en la solicitud del método. Si el punto de conexión de integración espera y devuelve cargas JSON sin comprimir, las plantillas de asignación configuradas para una carga JSON sin comprimir serán aplicables a la carga comprimida. En el caso de las cargas de solicitud de métodos comprimidas, API Gateway las descomprime, aplica la plantilla de asignación y pasa la solicitud comprimida al punto de conexión de integración. En el caso de las cargas de respuesta de integración sin comprimir, API Gateway aplica la plantilla de asignación, comprime la carga asignada y devuelve la carga comprimida al cliente. **Topics** + [Habilitación de la compresión de la carga para una API en API Gateway](api-gateway-enable-compression.md) + [Llamada a un método de API con una carga comprimida en API Gateway](api-gateway-make-request-with-compressed-payload.md) + [Recepción de una respuesta de API con una carga comprimida en API Gateway](api-gateway-receive-response-with-compressed-payload.md) # Habilitación de la compresión de la carga para una API en API Gateway Puede habilitar la compresión de una API mediante la consola de API Gateway, la AWS CLI o un AWS SDK. En el caso de una API existente, debe implementar la API después de habilitar la compresión para que el cambio surta efecto. Para una nueva API, puede implementar la API después de que se haya completado la configuración de la API. **nota** La codificación de contenido de mayor prioridad debe ser una compatible con la API Gateway. Si no es así, la compresión no se aplica a la carga de la respuesta. **Topics** + [Habilitación de la compresión de la carga en una API a través de la consola de API Gateway](#api-gateway-enable-compression-console) + [Habilitación de la compresión de carga en una API a través de la AWS CLI](#api-gateway-enable-compression-cli) + [Codificaciones de contenido admitidas por API Gateway](#api-gateway-supported-content-encodings) ## Habilitación de la compresión de la carga en una API a través de la consola de API Gateway En el siguiente procedimiento, se describe cómo habilitar la compresión de la carga en una API. **Para habilitar la compresión de carga a través de la consola de API Gateway** 1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway). 1. Seleccione una API existente o cree una nueva. 1. En el panel de navegación principal, elija **Configuración de la API**. 1. En la sección **Detalles de la API**, elija **Editar**. 1. Active la **codificación de contenido** para habilitar la compresión de carga. En **Tamaño mínimo del cuerpo**, ingrese un número para el tamaño mínimo de compresión (en bytes). Para desactivar la compresión, desactive la opción **codificación de contenido**. 1. Elija **Guardar cambios**. ## Habilitación de la compresión de carga en una API a través de la AWS CLI El siguiente comando [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) permite crear una API con compresión de la carga útil: ``` aws apigateway create-rest-api \ --name "My test API" \ --minimum-compression-size 0 ``` El siguiente comando [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html) permite habilitar la compresión de la carga útil para una API existente: ``` aws apigateway update-rest-api \ --rest-api-id 1234567890 \ --patch-operations op=replace,path=/minimumCompressionSize,value=0 ``` La propiedad `minimumCompressionSize` presenta un valor entero no negativo entre 0 y 10485760 (10 megabytes). Mide el umbral de compresión. Si el tamaño de la carga es menor que este valor, la compresión o la descompresión no se aplican en la carga. Si se establece en cero, la compresión está permitida para cualquier tamaño de carga. El siguiente comando [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html) permite desactivar la compresión de la carga útil: ``` aws apigateway update-rest-api \ --rest-api-id 1234567890 \ --patch-operations op=replace,path=/minimumCompressionSize,value= ``` También puede definir `value` en una cadena vacía `""` u omitir la propiedad `value` en su conjunto en la llamada anterior. ## Codificaciones de contenido admitidas por API Gateway API Gateway admite las siguientes codificaciones de código: + `deflate` + `gzip` + `identity` API Gateway también admite el siguiente formato de encabezado `Accept-Encoding`, conforme a la especificación [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4): + `Accept-Encoding:deflate,gzip` + `Accept-Encoding:` + `Accept-Encoding:*` + `Accept-Encoding:deflate;q=0.5,gzip;q=1.0` + `Accept-Encoding:gzip;q=1.0,identity;q=0.5,*;q=0` # Llamada a un método de API con una carga comprimida en API Gateway Para realizar una solicitud de API con una carga comprimida, el cliente debe configurar el encabezado `Content-Encoding` utilizando una de las [codificaciones de contenido admitidas](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). Supongamos que es un cliente de API y que quiere llamar al método PetStore (`POST /pets`). No llame al método utilizando la siguiente salida JSON: ``` POST /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Content-Length: ... { "type": "dog", "price": 249.99 } ``` En su lugar, puede llamar al método con la misma carga comprimida utilizando la codificación GZIP: ``` POST /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Content-Encoding:gzip Content-Length: ... ���RPP*�,HU�RPJ�OW��e&���L,�,-y�j ``` Cuando API Gateway recibe la solicitud, comprueba si la codificación de contenido especificada es compatible. A continuación, intenta descomprimir la carga con la codificación de contenido especificada. Si la descompresión se realiza correctamente, envía la solicitud al punto de conexión de integración. Si la codificación especificada no es compatible o la carga suministrada no está comprimida con la codificación especificada, API Gateway devuelve la respuesta de error `415 Unsupported Media Type`. El error no se registra en CloudWatch Logs, si se produce en las fases iniciales de descompresión antes de que se identifiquen la API y la etapa. # Recepción de una respuesta de API con una carga comprimida en API Gateway Cuando realiza una solicitud en una API habilitada para la compresión, el cliente puede optar por recibir una carga de respuesta comprimida de un formato específico especificando un encabezado `Accept-Encoding` con una [codificación de contenido compatible](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). API Gateway solo comprime la carga de respuesta cuando se cumplen las siguientes condiciones: + La solicitud entrante tiene el encabezado `Accept-Encoding` con el formato y la codificación de contenido compatibles. **nota** Si no se define el encabezado, el valor predeterminado es `*` tal y como se define en [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4). En tal caso, API Gateway no comprime la carga útil. Algunos navegadores o clientes pueden añadir `Accept-Encoding` (por ejemplo `Accept-Encoding:gzip, deflate, br`) automáticamente para las solicitudes habilitadas para compresión. Esto puede activar la compresión de la carga útil en API Gateway. Sin una especificación explícita de los valores del encabezado `Accept-Encoding` admitidos, API Gateway no comprime la carga. + `minimumCompressionSize` está establecido en la API para habilitar la compresión. + La respuesta de integración no tiene un encabezado `Content-Encoding`. + El tamaño de la carga de respuesta de integración, una vez que se aplica la plantilla de asignación correspondiente, es mayor o igual que el valor `minimumCompressionSize` especificado. API Gateway aplica una plantilla de asignación configurada para la respuesta de integración antes de que se comprima la carga. Si la respuesta de integración contiene un encabezado `Content-Encoding`, API Gateway presupone que la carga de respuesta de integración ya está comprimida y omite el proceso de compresión. Un ejemplo de esto es el de la API de PetStore y la siguiente solicitud: ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept: application/json ``` El backend responde a la solicitud con una carga JSON sin comprimir similar a la siguiente: ``` 200 OK [ { "id": 1, "type": "dog", "price": 249.99 }, { "id": 2, "type": "cat", "price": 124.99 }, { "id": 3, "type": "fish", "price": 0.99 } ] ``` Para recibir esta salida como una carga comprimida, el cliente de la API puede enviar una solicitud como la siguiente: ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept-Encoding:gzip ``` El cliente recibe la respuesta con un encabezado `Content-Encoding` y una carga codificada en GZIP similar a la siguiente: ``` 200 OK Content-Encoding:gzip ... ���RP� J�)JV �:P^IeA*������+(�L �X�YZ�ku0L0B7!9��C#�&����Y��a���^�X ``` Cuando la carga de respuesta está comprimida, solo el tamaño de los datos comprimidos se tiene en cuenta al facturar la transferencia de información.