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. # 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.