Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Empfangen einer API-Antwort mit einer komprimierten Nutzlast in API Gateway Beim Erstellen einer Anforderung in einer komprimierungsfähigen API kann der Client festlegen, dass er eine komprimierte Antwortnutzlast eines bestimmten Formats erhält, indem er einen `Accept-Encoding`-Header mit einer [unterstützten Inhaltscodierung](api-gateway-enable-compression.md#api-gateway-supported-content-encodings) angibt. API Gateway komprimiert den Antwortpayload nur, wenn die folgenden Bedingungen erfüllt sind: + Der `Accept-Encoding`-Header der eingehenden Anforderung weist eine unterstützte Inhaltscodierung und ein entsprechendes Format auf. **Anmerkung** Wenn der Header nicht festgelegt ist, ist der Standardwert `*` gemäß [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4). In einem solchen Fall komprimiert API Gateway den Payload nicht. Einige Browser oder Clients fügen komprimierungsfähigen Anforderungen möglicherweise automatisch `Accept-Encoding` (z. B. `Accept-Encoding:gzip, deflate, br`) hinzu. Dies kann die Komprimierung der Nutzlast in API Gateway aktivieren. Ohne explizite Angabe der unterstützten `Accept-Encoding`-Header-Werte komprimiert API Gateway den Payload nicht. + Die `minimumCompressionSize` wird in der API festgelegt, um die Komprimierung zu aktivieren. + Die Integrationsantwort enthält keinen `Content-Encoding`-Header. + Die Größe einer Integrationsantwortnutzlast nach Anwendung der geltenden Zuweisungsvorlage ist größer als oder gleich dem angegebenen `minimumCompressionSize`-Wert. API Gateway wendet ggf. eine Zuweisungsvorlagen an, die für die Integrationsantwort konfiguriert ist, bevor die Nutzlast komprimiert wird. Wenn die Integrationsantwort einen `Content-Encoding`-Header enthält, geht API Gateway davon aus, dass die Integrationsantwortnutzlast bereits komprimiert ist und überspringt die Komprimierungsverarbeitung. Ein Beispiel ist das PetStore API-Beispiel und die folgende Anfrage: ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept: application/json ``` Das Backend beantwortet die Anforderung mit einer nicht komprimierten JSON-Nutzlast ähnlich wie der folgenden: ``` 200 OK [ { "id": 1, "type": "dog", "price": 249.99 }, { "id": 2, "type": "cat", "price": 124.99 }, { "id": 3, "type": "fish", "price": 0.99 } ] ``` Zum Empfangen dieser Ausgabe als komprimierte Nutzlast kann Ihr API-Client eine Anforderung wie folgt senden: ``` GET /pets Host: {petstore-api-id}.execute-api.{region}.amazonaws.com Accept-Encoding:gzip ``` Der Client erhält die Antwort mit einem `Content-Encoding`-Header und einer GZIP-kodierten Nutzlast ähnlich wie den folgenden: ``` 200 OK Content-Encoding:gzip ... ���RP� J�)JV �:P^IeA*������+(�L �X�YZ�ku0L0B7!9��C#�&����Y��a���^�X ``` Wird die Antwortnutzlast komprimiert, wird nur die komprimierte Datengröße für die Datenübertragung in Rechnung gestellt.