Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Optimisez les performances de REST APIs Une fois que vous avez rendu votre API disponible en appel, vous pouvez constater qu’elle doit être optimisée pour améliorer sa réactivité. API Gateway fournit quelques politiques d’optimisation de votre API, comme la mise en cache de réponse et la compression de la charge utile. Dans cette section, vous pouvez apprendre à activer ces fonctionnalités. **Topics** + [Paramètres de cache pour REST APIs dans API Gateway](api-gateway-caching.md) + [Compression de charge utile pour REST APIs dans API Gateway](api-gateway-gzip-compression-decompression.md) # Paramètres de cache pour REST APIs dans API Gateway Vous pouvez activer la mise en cache des API dans API Gateway pour mettre en cache les réponses de votre point de terminaison. Avec la mise en cache, vous pouvez réduire le nombre d’appels envoyés à votre point de terminaison et également améliorer la latence des demandes adressées à votre API. Lorsque vous activez la mise en cache pour une étape, API Gateway met en cache les réponses de votre point de terminaison pendant une période spécifiée time-to-live (TTL), en secondes. API Gateway répond ensuite à la demande en recherchant la réponse du point de terminaison dans le cache au lieu d’envoyer une demande à votre point de terminaison. La valeur TTL par défaut pour la mise en cache des API est 300 secondes. La valeur TTL maximale est 3 600 secondes. La valeur TTL = 0 signifie que la mise en cache est désactivée. **Note** La mise en cache est la meilleure solution. Vous pouvez utiliser les `CacheMissCount` métriques `CacheHitCount` et d'Amazon CloudWatch pour surveiller les demandes traitées par API Gateway à partir du cache d'API. La taille maximale d’une réponse qui peut être mise en cache est de 1 048 576 octets. Le chiffrement des données de cache peut augmenter la taille de la réponse lorsqu’elle est mise en cache. Il s’agit d’un service admissible en vertu de la loi HIPAA. Pour plus d'informations sur AWS le Health Insurance Portability and Accountability Act des États-Unis de 1996 (HIPAA) et sur l'utilisation de AWS services pour traiter, stocker et transmettre des informations de santé protégées (PHI), consultez la section Présentation de la [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). **Important** Lorsque vous activez la mise en cache pour une étape, elle est activée seulement pour les méthodes `GET` par défaut. Cela permet d’assurer la sécurité et la disponibilité de votre API. Vous pouvez activer la mise en cache pour d’autres méthodes en [remplaçant les paramètres de méthode](#override-api-gateway-stage-cache-for-method-cache). **Important** La mise en cache est facturée à l’heure en fonction de la taille du cache que vous avez choisie. La mise en cache n'est pas éligible au niveau AWS gratuit. Pour plus d’informations, consultez [API Gateway Pricing](https://aws.amazon.com/api-gateway/pricing/) (Tarification d’API Gateway). ## Activation de la mise en cache Amazon API Gateway Dans API Gateway, vous pouvez activer la mise en cache pour une étape spécifique. Lorsque vous activez la mise en cache, vous devez choisir une capacité de cache. En général, une plus grande capacité offre de meilleures performances, mais coûte également plus cher. Pour connaître les tailles de cache prises [cacheClusterSize](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateStage.html#apigw-CreateStage-request-cacheClusterSize)en charge, consultez le *guide API Gateway API Reference*. API Gateway active la mise en cache en créant une instance de cache dédiée. Ce processus peut prendre jusqu’à 4 minutes. API Gateway modifie la capacité de mise en cache en supprimant l’instance de cache existante et en en créant une avec une nouvelle capacité. Toutes les données mises en cache existantes sont supprimées. **Note** La capacité du cache affecte le processeur, la mémoire et la bande passante réseau de l’instance de cache. Par conséquent, la capacité du cache peut affecter les performances de ce dernier. API Gateway vous recommande d’exécuter un test de charge de 10 minutes pour vérifier que votre capacité de cache est appropriée à votre charge de travail. Assurez-vous que le trafic pendant le test de charge reflète le trafic de production. Par exemple, incluez la montée en puissance, le trafic constant et les pics de trafic. Le test de charge doit inclure des réponses pouvant être fournies à partir du cache, ainsi que des réponses uniques qui ajoutent des éléments au cache. Surveillez les mesures de latence, 4xx, 5xx, d’accès au cache et d’échec d’accès au cache pendant le test de charge. Ajustez votre capacité de cache selon vos besoins en fonction de ces mesures. Pour obtenir plus d’informations sur les tests de charge, consultez l’article [How do I select the best API Gateway cache capacity to avoid hitting a rate limit?](https://repost.aws/knowledge-center/api-gateway-cache-capacity) (Comment sélectionner la meilleure capacité de cache d’API Gateway pour éviter de se heurter à une limite de débit ?). ------ #### [ AWS Management Console ] Dans la console API Gateway, la mise en cache est configurée à la page **Étapes**. Vous allez configurer le cache de l’étape et spécifier un paramètre de cache au niveau de la méthode par défaut. Si vous activez le cache au niveau de la méthode par défaut, la mise en cache au niveau de la méthode est activée pour toutes les méthodes `GET` de votre étape, à moins que cette méthode comporte un remplacement de méthode. Toutes les méthodes `GET` supplémentaires que vous déployez pour votre étape disposeront d’un cache au niveau de la méthode. Pour configurer le paramètre de mise en cache au niveau de la méthode pour des méthodes spécifiques de votre étape, vous pouvez utiliser des remplacements de méthode. Pour plus d’informations sur les remplacements de méthode, consultez [Remplacement de la mise en cache au niveau de l’étape API Gateway par la mise en cache au niveau de la méthode](#override-api-gateway-stage-cache-for-method-cache). **Pour configurer la mise en cache des API pour une étape donnée :** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Choisissez **Stages (Étapes)**. 1. Dans la liste **Stages (Étapes)** de l’API, choisissez l’étape. 1. Dans la section **Détails de l’étape**, choisissez **Modifier**. 1. Sous **Paramètres supplémentaires**, pour **Paramètres de cache**, activez **Configurer le cache d’API**. Cette opération configure un cluster de cache pour votre étape. 1. Pour activer la mise en cache pour votre étape, activez **Mise en cache au niveau de la méthode par défaut**. La mise en cache au niveau de la méthode est alors activée pour toutes les méthodes `GET` de votre étape. Toutes les méthodes `GET` supplémentaires que vous déployez pour cette étape disposeront d’un cache au niveau de la méthode. **Note** S’il existe déjà un paramètre de cache au niveau de la méthode, celui-ci ne sera pas affecté par la modification du paramètre de cache au niveau de la méthode par défaut. ![\[Activation de la configuration du cache d’API et de la mise en cache au niveau de la méthode par défaut.\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/api-caching-stage-flow.png) 1. Sélectionnez **Enregistrer les modifications**. ------ #### [ AWS CLI ] La commande [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) suivante met à jour une étape afin de configurer un cache, et active la mise en cache au niveau de la méthode de toutes les méthodes `GET` de votre étape : ``` aws apigateway update-stage \ --rest-api-id a1b2c3 \ --stage-name 'prod' \ --patch-operations file://patch.json ``` Le contenu de `patch.json` est le suivant : ``` [ { "op": "replace", "path": "/cacheClusterEnabled", "value": "true" }, { "op": "replace", "path": "/cacheClusterSize", "value": "0.5" }, { "op": "replace", "path": "/*/*/caching/enabled", "value": "true" } ] ``` **Note** S’il existe déjà un paramètre de cache au niveau de la méthode, celui-ci ne sera pas affecté par la modification du paramètre de cache au niveau de la méthode par défaut. ------ **Note** Le processus de création ou de suppression d’un cache prend environ 4 minutes dans API Gateway. Lorsqu’un cache est créé, la valeur du champ **Cluster de cache** passe de `Create in progress` à `Active`. Lorsqu’un cache est supprimé, la valeur du champ **Cluster de cache** passe de `Delete in progress` à `Inactive`. Lorsque vous activez la mise en cache au niveau de la méthode pour toutes les méthodes de votre étape, la valeur **Mise en cache au niveau de la méthode par défaut** devient `Active`. Si vous désactivez la mise en cache au niveau de la méthode pour toutes les méthodes de votre étape, la valeur **Mise en cache au niveau de la méthode par défaut** devient `Inactive`. S’il existe déjà un paramètre de cache au niveau de la méthode, il ne sera pas affecté par la modification du statut du cache. Lorsque vous activez la mise en cache dans la section **Paramètres de cache** d’une étape, seules les méthodes `GET` sont mises en cache. Pour assurer la sécurité et la disponibilité de votre API, nous vous recommandons de ne pas modifier ce paramètre. Vous pouvez cependant activer la mise en cache pour d’autres méthodes en [remplaçant les paramètres de méthode](#override-api-gateway-stage-cache-for-method-cache). Si vous souhaitez vérifier si la mise en cache fonctionne comme prévu, vous avez deux options générales : + Inspectez les CloudWatch métriques de **CacheHitCount**et **CacheMissCount**pour votre API et votre stage. + Placez un horodatage dans la réponse. **Note** N'utilisez pas l'`X-Cache`en-tête de la CloudFront réponse pour déterminer si votre API est servie à partir de votre instance de cache d'API Gateway. ## Remplacement de la mise en cache au niveau de l’étape API Gateway par la mise en cache au niveau de la méthode Vous pouvez remplacer les paramètres de cache au niveau de l’étape en activant ou en désactivant la mise en cache d’une méthode spécifique. Vous pouvez également modifier la période TTL, ou activer ou désactiver le chiffrement des réponses mises en cache. Si vous prévoyez qu’une méthode que vous mettez en cache recevra des données sensibles dans ses réponses, chiffrez les données du cache. Vous devrez peut-être le faire pour vous conformer aux différents cadres de conformité. Pour plus d’informations, consultez [Amazon API Gateway controls](https://docs.aws.amazon.com/securityhub/latest/userguide/apigateway-controls.html) dans le *Guide de l’utilisateur AWS Security Hub *. ------ #### [ AWS Management Console ] Si vous modifiez le paramètre de mise en cache au niveau de la méthode par défaut dans **Détails de l’étape**, les paramètres de cache au niveau de la méthode ayant des remplacements n’en seront pas affectés. Si vous prévoyez qu’une méthode que vous mettez en cache va recevoir des données sensibles dans ses réponses, dans **Cache Settings (Paramètres de cache)**, sélectionnez **Encrypt cache data (Chiffrer les données de cache)**. **Pour configurer la mise en cache des API pour les méthodes individuelles à l’aide de la console :** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Choisissez l’API. 1. Choisissez **Stages (Étapes)**. 1. Dans la liste **Stages (Étapes)** de l’API, développez l’étape et choisissez une méthode dans l’API. 1. Dans la section **Dérogations de méthode**, choisissez **Modifier**. 1. Dans la section **Paramètres de méthode**, activez ou désactivez **Activer le cache de la méthode** ou personnalisez les autres options souhaitées. **Note** La mise en cache n’est pas active tant que vous n’avez pas configuré un cluster de cache pour votre étape. 1. Choisissez **Enregistrer**. ------ #### [ AWS CLI ] La commande [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) suivante désactive le cache uniquement pour la méthode `GET /pets` : ``` aws apigateway update-stage / --rest-api-id a1b2c3 / --stage-name 'prod' / --patch-operations file://patch.json ``` Le contenu de `patch.json` est le suivant : ``` [{ "op": "replace", "path": "/~1pets/GET/caching/enabled", "value": "false" }] ``` ------ ## Utilisation de paramètres de méthode ou d’intégration en tant que clés de cache pour indexer les réponses mises en cache Vous pouvez utiliser un paramètre de méthode ou d’intégration en tant que clés de cache pour indexer les réponses mises en cache. Cela inclut les en-têtes personnalisés, les chemins d’URL ou les chaînes de requête. Vous pouvez spécifier tout ou partie de ces paramètres comme clé de cache, mais vous devez spécifier au moins une valeur. Si vous disposez d’une clé de cache, API Gateway met en cache les réponses de chaque valeur de clé séparément, y compris en l’absence de la clé de cache. **Note** Les clés de cache sont obligatoires lorsque vous configurez la mise en cache d’une ressource. Par exemple, supposons que vous avez une demande au format suivant : ``` GET /users?type=... HTTP/1.1 host: example.com ... ``` Dans cette demande, `type` peut prendre la valeur `admin` ou `regular`. Si vous incluez le paramètre `type` dans la clé de cache, les réponses de `GET /users?type=admin` sont mises en cache séparément de celles de `GET /users?type=regular`. Lorsqu’une demande de méthode ou d’intégration utilise plus d’un paramètre, vous pouvez choisir d’inclure certains ou la totalité des paramètres pour créer la clé de cache. Par exemple, vous pouvez inclure uniquement le paramètre `type` dans la clé de cache pour la demande suivante, effectuée dans l’ordre indiqué pendant une période TTL : ``` GET /users?type=admin&department=A HTTP/1.1 host: example.com ... ``` La réponse de cette demande est mise en cache et elle est utilisée pour servir la demande suivante : ``` GET /users?type=admin&department=B HTTP/1.1 host: example.com ... ``` ------ #### [ AWS Management Console ] Pour inclure un paramètre de demande de méthode ou d’intégration dans une clé de cache dans la console API Gateway, sélectionnez **Caching (Mise en cache)** après avoir ajouté le paramètre. ![\[Inclusion de paramètres de méthode ou d’intégration en tant que clés de cache pour indexer les réponses mises en cache\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/api-caching-including-parameter-as-cache-key-new-console.png) ------ #### [ AWS CLI ] La commande [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) suivante crée une méthode `GET` et exige le paramètre de chaîne de requête `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" ``` La commande [put-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration.html) suivante crée une intégration pour la méthode `GET` avec un point de terminaison HTTP, et indique qu’API Gateway met en cache le paramètre de demande de méthode `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" ``` Pour spécifier à API Gateway de mettre en cache un paramètre de demande d’intégration, utilisez `integration.request.location.name` comme paramètre de clé de cache. ------ ## Vidage du cache d’étape d’API dans API Gateway Lorsque la mise en cache des API est activée, vous pouvez vider le cache au niveau d’une étape d’API afin de garantir que les clients de l’API obtiennent les réponses les plus récentes de vos points de terminaison d’intégration. ------ #### [ AWS Management Console ] **Pour vider le cache de l’étape d’API** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Choisissez une API dotée d’une étape avec un cache. 1. Dans le volet de navigation principal, choisissez **Étapes**, puis sélectionnez une étape avec un cache. 1. Choisissez le menu **Actions d’étape**, puis sélectionnez **Vider le cache d’étape**. ------ #### [ AWS CLI ] La [flush-stage-cache](https://docs.aws.amazon.com/cli/latest/reference/apigateway/flush-stage-cache.html)commande suivante vide le cache de la scène : ``` aws apigateway flush-stage-cache \ --rest-api-id a1b2c3 \ --stage-name prod ``` ------ **Note** Une fois que le cache est vidé, les réponses sont traitées à partir du point de terminaison d’intégration jusqu’à ce que le cache soit recréé. Durant cette période, le nombre de demandes envoyées au point de terminaison d’intégration peut augmenter. Cela peut temporairement augmenter la latence globale de votre API. ## Invalidation d’une entrée de cache API Gateway Un client de votre API peut invalider une entrée de cache existante et la recharger à partir du point de terminaison d’intégration pour les différentes demandes. Le client doit envoyer une demande contenant l’en-tête `Cache-Control: max-age=0`. Le client reçoit la réponse directement du point de terminaison d’intégration et non du cache, sous réserve qu’il dispose de l’autorisation nécessaire. L’entrée de cache existante est alors remplacée par la nouvelle réponse, qui est extraite du point de terminaison d’intégration. Pour accorder cette autorisation à un client, attachez une politique au format suivant à un rôle d’exécution IAM pour l’utilisateur. **Note** L’invalidation du cache entre comptes n’est pas prise en charge. ------ #### [ 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" ] } ] } ``` ------ Cette politique autorise le service d’exécution API Gateway à invalider le cache pour les demandes sur les ressources spécifiées. Pour spécifier un groupe de ressources ciblées, utilisez un caractère générique (\$1) pour `account-id`, `api-id` et les autres entrées de la valeur d’ARN de `Resource`. Pour plus d’informations sur la définition d’autorisations pour le service d’exécution API Gateway, consultez [Contrôle de l’accès à une API REST avec des autorisations IAM](permissions.md). Si vous n’imposez aucune politique `InvalidateCache` (ou si vous activez la case à cocher **Require authorization (Exiger une autorisation)** dans la console), n’importe quel client peut invalider le cache API. Si tous les clients ou la plupart d’entre eux invalident le cache API, cela peut augmenter la latence de votre API de façon significative. Lorsque la politique est en place, la mise en cache est activée et l’autorisation est requise. Vous pouvez définir la manière dont API Gateway traite les demandes non autorisées en choisissant l’une des options suivantes : **Faire échouer la requête avec le code d’état 403** API Gateway renvoie une réponse `403 Unauthorized`. Pour définir cette option à l'aide de l'API, utilisez `FAIL_WITH_403`. **Ignorer l’en-tête de contrôle du cache et ajouter un avertissement dans l’en-tête de la réponse** API Gateway traite la demande et ajoute un en-tête d’avertissement dans la réponse. Pour définir cette option à l'aide de l'API, utilisez `SUCCEED_WITH_RESPONSE_HEADER`. **Ignorer l’en-tête de contrôle du cache** API Gateway traite la demande sans ajouter d’en-tête d’avertissement dans la réponse. Pour définir cette option à l'aide de l'API, utilisez `SUCCEED_WITHOUT_RESPONSE_HEADER`. Vous pouvez définir le comportement de traitement des demandes non autorisées à l’aide de la console API Gateway ou de l’ AWS CLI. ------ #### [ AWS Management Console ] **Pour spécifier le mode de traitement des demandes non autorisées** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Choisissez une API dotée d’une étape avec un cache. 1. Dans le volet de navigation principal, choisissez **Étapes**, puis sélectionnez une étape avec un cache. 1. Sous **Détails de l’étape**, choisissez **Modifier**. 1. Sous **Traitement des requêtes non autorisées**, sélectionnez une option. 1. Sélectionnez **Continuer**. 1. Passez en revue vos modifications et choisissez **Enregistrer les modifications**. ------ #### [ AWS CLI ] La commande [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) suivante met à jour une étape afin qu’elle gère les demandes non autorisées en rejetant la demande avec le code d’état 403 : ``` aws apigateway update-stage / --rest-api-id a1b2c3 / --stage-name 'prod' / --patch-operations 'op=replace,path=/*/*/caching/unauthorizedCacheControlHeaderStrategy,value="FAIL_WITH_403"' ``` ------ ## CloudFormation exemple d'une étape avec un cache Le CloudFormation modèle suivant crée un exemple d'API, fournit un cache de `0.5` Go pour la `Prod` phase et active la mise en cache au niveau de la méthode pour toutes les méthodes. `GET` **Important** La mise en cache est facturée à l’heure en fonction de la taille du cache que vous avez choisie. La mise en cache n’est pas éligible pour l’offre gratuite AWS . Pour plus d’informations, consultez [API Gateway Pricing](https://aws.amazon.com/api-gateway/pricing/) (Tarification d’API Gateway). ### Exemple de CloudFormation modèle ``` 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 ``` # Compression de charge utile pour REST APIs dans API Gateway API Gateway permet au client d’appeler votre API avec des charges utiles compressées à l’aide de l’un des [codages de contenu pris en charge](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). Par défaut, API Gateway prend en charge la décompression de la charge utile de la demande de méthode. Cependant, vous devez configurer votre API pour activer la compression de la charge utile de la réponse de la méthode. Pour activer la compression sur une [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html), définissez la propriété [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize) sur un nombre entier positif compris entre 0 et 10485760 (10 Mo) lorsque vous créez l’API ou une fois que vous l’avez créée. Pour désactiver la compression sur l’API, définissez l’attribut `minimumCompressionSize` sur null ou supprimez-le complètement. Vous pouvez activer ou désactiver la compression pour une API à l'aide de la console API Gateway, de l' AWS CLI API REST API Gateway ou de l'API REST API Gateway. Si vous souhaitez que la compression soit appliquée sur une charge utile de n’importe quelle taille, définissez la valeur `minimumCompressionSize` sur zéro. Toutefois, la compression des données de petite taille peut augmenter la taille des données finales. En outre, la compression dans API Gateway et la décompression dans le client peuvent accroître la latence globale et nécessitent plus de temps de calcul. Vous devez exécuter des tests par rapport à vos API afin de déterminer une valeur optimale. Le client peut envoyer une demande d’API avec une charge utile compressée et un en-tête `Content-Encoding` approprié pour qu’API Gateway décompresse et applique les modèles de mappage appropriés avant de transmettre la demande au point de terminaison d’intégration. Une fois que la compression est activée et que l’API est déployée, le client peut recevoir une réponse d’API avec une charge utile compressée s’il spécifie un en-tête `Accept-Encoding` approprié dans la demande de méthode. Lorsque le point de terminaison d’intégration attend et renvoie des charges utiles JSON non compressées, les modèles de mappage qui sont configurés pour une charge utile JSON non compressée sont applicables à la charge utile compressée. Pour la charge utile d’une demande de méthode compressée, API Gateway décompresse la charge utile, applique le modèle de mappage et transmet la demande mappée au point de terminaison d’intégration. Pour la charge utile d’une réponse d’intégration non compressée, API Gateway applique le modèle de mappage, compresse la charge utile mappée et renvoie la charge utile compressée au client. **Topics** + [Activation de la compression des données utiles pour une API dans API Gateway](api-gateway-enable-compression.md) + [Appel d’une méthode d’API avec des données utiles compressées dans API Gateway](api-gateway-make-request-with-compressed-payload.md) + [Réception d’une réponse d’API avec des données utiles compressées dans API Gateway](api-gateway-receive-response-with-compressed-payload.md) # Activation de la compression des données utiles pour une API dans API Gateway Vous pouvez activer la compression pour une API à l'aide de la console API Gateway AWS CLI, du ou d'un AWS SDK. Pour une API existante, vous devez déployer l’API après avoir activé la compression pour que la modification entre en vigueur. Pour une nouvelle API, vous pouvez déployer l’API une fois sa configuration terminée. **Note** La priorité d’encodage de contenu la plus élevée doit être prise en charge par API Gateway. Si ce n’est pas le cas, la compression n’est pas appliquée à la charge utile de la réponse. **Topics** + [Activation de la compression de charge utile pour une API à l’aide de la console API Gateway](#api-gateway-enable-compression-console) + [Activez la compression de charge utile pour une API à l'aide du AWS CLI](#api-gateway-enable-compression-cli) + [Codages de contenu pris en charge par API Gateway](#api-gateway-supported-content-encodings) ## Activation de la compression de charge utile pour une API à l’aide de la console API Gateway La procédure suivante décrit comment activer la compression de la charge utile pour une API. **Pour activer la compression de la charge utile à l’aide de la console API Gateway** 1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway) 1. Choisissez une API existante ou créez-en une. 1. Dans le panneau de navigation principal, choisissez **Paramètres de l’API**. 1. Dans la section **Détails de l’API**, choisissez **Modifier**. 1. Activez **Encodage de contenu** pour activer la compression de la charge utile. Pour **Taille minimale du corps**, entrez un nombre pour la taille de compression minimale (en octets). Pour désactiver la compression, désactivez l’option **Encodage de contenu**. 1. Sélectionnez **Enregistrer les modifications**. ## Activez la compression de charge utile pour une API à l'aide du AWS CLI La [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html)commande suivante crée une API avec compression de charge utile : ``` aws apigateway create-rest-api \ --name "My test API" \ --minimum-compression-size 0 ``` La [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html)commande suivante active la compression de charge utile pour une API existante : ``` aws apigateway update-rest-api \ --rest-api-id 1234567890 \ --patch-operations op=replace,path=/minimumCompressionSize,value=0 ``` La propriété `minimumCompressionSize` possède un nombre entier non négatif compris entre 0 et 10485760 (10 Mo). Elle mesure le seuil de compression. Si la taille de charge est inférieure à cette valeur, la compression ou décompression ne sont pas appliquées sur la charge utile. La définition de l’option sur zéro permet la compression de n’importe quelle taille de charge utile. La [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html)commande suivante désactive la compression de la charge utile : ``` aws apigateway update-rest-api \ --rest-api-id 1234567890 \ --patch-operations op=replace,path=/minimumCompressionSize,value= ``` Vous pouvez également définir `value` sur une chaîne vide `""` ou omettez la propriété `value` complètement dans l’appel précédent. ## Codages de contenu pris en charge par API Gateway API Gateway prend en charge les codages de contenu suivants : + `deflate` + `gzip` + `identity` API Gateway prend également en charge le format d’en-tête `Accept-Encoding` suivant, conformément à la spécification [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` # Appel d’une méthode d’API avec des données utiles compressées dans API Gateway Pour effectuer une demande d’API avec une charge utile compressée, le client doit définir l’en-tête `Content-Encoding` avec l’un des [codages de contenu pris en charge](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). Supposons que vous soyez un client d'API et que vous souhaitiez appeler la méthode PetStore API (`POST /pets`). N’appelez pas cette méthode avec la sortie JSON suivante : ``` POST /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Content-Length: ... { "type": "dog", "price": 249.99 } ``` Au lieu de cela, vous pouvez appeler la méthode avec la même charge utile compressée en utilisant le codage 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 ``` Lorsqu’API Gateway reçoit la demande, il vérifie si le codage de contenu spécifié est pris en charge. Ensuite, il tente de décompresser la charge utile avec le codage de contenu spécifié. Si la décompression est réussie, il envoie la demande au point de terminaison d’intégration. Si le codage spécifié n’est pas pris en charge ou si la charge utile fournie n’est pas compressée avec le codage spécifié, API Gateway renvoie la réponse d’erreur `415 Unsupported Media Type`. L'erreur n'est pas enregistrée dans CloudWatch Logs si elle survient au début de la phase de décompression avant que votre API et votre stage ne soient identifiés. # Réception d’une réponse d’API avec des données utiles compressées dans API Gateway Lorsque vous effectuez une demande pour une API dont la compression est activée, le client peut choisir de recevoir une charge utile de réponse compressée dans un format spécifique en spécifiant un en-tête `Accept-Encoding` avec un [codage de contenu pris en charge](api-gateway-enable-compression.md#api-gateway-supported-content-encodings). API Gateway ne compresse la charge utile de la réponse que lorsque les conditions suivantes sont satisfaites : + La demande entrante a l’en-tête `Accept-Encoding` avec un format et un codage de contenu pris en charge. **Note** Si l’en-tête n’est pas défini, la valeur par défaut est `*` telle que définie dans [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4). Dans ce cas, API Gateway ne compresse pas la charge utile. Certains navigateurs ou clients peuvent ajouter `Accept-Encoding` (par exemple, `Accept-Encoding:gzip, deflate, br`) automatiquement aux requêtes dont la compression est activée. Cela permet d’activer la compression des données utiles dans API Gateway. Sans une spécification explicite des valeurs d’en-tête `Accept-Encoding` prises en charge, API Gateway ne compresse pas la charge utile. + La valeur `minimumCompressionSize` est définie sur l’API pour activer la compression. + La réponse d’intégration ne dispose pas d’en-tête `Content-Encoding`. + La taille de la charge utile d’une réponse d’intégration corps après l’application du modèle de mappage approprié est supérieure ou égale à la valeur `minimumCompressionSize` spécifiée. API Gateway applique n’importe quel modèle de mappage configuré pour la réponse d’intégration avant de compresser la charge utile. Si la réponse d’intégration contient un en-tête `Content-Encoding`, API Gateway suppose que la charge utile de la réponse d’intégration est déjà compressée et omet le traitement de compression. L'exemple d' PetStore API et la requête suivante en sont un exemple : ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept: application/json ``` Le back-end répond à la demande avec une charge utile JSON non compressée qui est semblable à ce qui suit : ``` 200 OK [ { "id": 1, "type": "dog", "price": 249.99 }, { "id": 2, "type": "cat", "price": 124.99 }, { "id": 3, "type": "fish", "price": 0.99 } ] ``` Pour recevoir cette sortie en tant que charge utile compressée, votre client d’API peut soumettre une demande comme suit : ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept-Encoding:gzip ``` Le client reçoit la réponse avec un en-tête `Content-Encoding` et une charge utile encodée GZIP similaires à ce qui suit : ``` 200 OK Content-Encoding:gzip ... ���RP� J�)JV �:P^IeA*������+(�L �X�YZ�ku0L0B7!9��C#�&����Y��a���^�X ``` Lorsque la charge utile de la réponse est compressée, seule la taille des données compressées est facturée pour le transfert de données.