

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.

# Optimieren Sie die Leistung von REST APIs
<a name="rest-api-optimize"></a>

Nachdem Sie Ihre API für den Aufruf zur Verfügung gestellt haben, stellen Sie vielleicht fest, dass sie optimiert werden muss, um die Reaktionsfähigkeit zu verbessern. API Gateway bietet einige Strategien zur Optimierung Ihrer API, wie Antwort-Caching und Payload-Komprimierung. In diesem Abschnitt erfahren Sie, wie Sie diese Funktionen aktivieren.

**Topics**
+ [Cache-Einstellungen für REST APIs in API Gateway](api-gateway-caching.md)
+ [Payload-Komprimierung für REST APIs in API Gateway](api-gateway-gzip-compression-decompression.md)

# Cache-Einstellungen für REST APIs in API Gateway
<a name="api-gateway-caching"></a>

Sie können API-Caching in Amazon API Gateway aktivieren, um die Antworten Ihres Endpunkts im Cache zu speichern. Mit Caching können Sie die Anzahl der an Ihren Endpunkt gemachten Aufrufe verringern und die Latenz der Anforderungen an Ihre API verbessern.

Wenn Sie das Caching für eine Phase aktivieren, speichert API Gateway Antworten von Ihrem Endpunkt für einen bestimmten Zeitraum time-to-live (TTL) in Sekunden zwischen. Anschließend beantwortet API Gateway die Anfrage, indem es die Endpunkt-Antwort aus dem Cache ausliest, anstatt eine Anfrage an Ihren Endpunkt zu senden. Der Standard-TTL-Wert für API-Caching ist 300 Sekunden. Die maximale TTL-Wert ist 3.600 Sekunden. TTL = 0 bedeutet, dass die Zwischenspeicherung deaktiviert ist.

**Anmerkung**  
Caching ist die sinnvollste Tätigkeit. Sie können die `CacheMissCount` Metriken `CacheHitCount` und in Amazon verwenden CloudWatch , um Anfragen zu überwachen, die API Gateway aus dem API-Cache bedient.

Die maximale Größe einer Antwort, die zwischengespeichert werden kann, ist 1 048 576 Bytes. Die Cache-Datenverschlüsselung kann die Größe der Antwort erhöhen, wenn sie zwischengespeichert wird.

Dies ist ein HIPAA-berechtigter Service. [Weitere Informationen AWS zum US-amerikanischen Health Insurance Portability and Accountability Act von 1996 (HIPAA) und zur Nutzung von AWS Diensten zur Verarbeitung, Speicherung und Übertragung geschützter Gesundheitsinformationen (PHI) finden Sie unter HIPAA Overview.](https://aws.amazon.com/compliance/hipaa-compliance/)

**Wichtig**  
Wenn Sie das Caching für eine Stufe aktivieren, wird standardmäßig nur die Zwischenspeicherung von `GET`-Methoden aktiviert. Dies hilft, die Sicherheit und die Verfügbarkeit Ihrer API zu gewährleisten. Sie können das Caching für andere Methoden [ aktivieren, indem Sie die Methodeneinstellungen überschreiben](#override-api-gateway-stage-cache-for-method-cache).

**Wichtig**  
Caching wird basierend auf der von Ihnen ausgewählten Cache-Größe nach Stunden berechnet. Caching kommt nicht für das kostenlose Kontingent in Frage. AWS Weitere Informationen finden Sie unter [API-Gateway-Preise](https://aws.amazon.com/api-gateway/pricing/).

## Caching von Amazon API Gateway aktivieren
<a name="enable-api-gateway-caching"></a>

In API Gateway können Sie das Caching für eine bestimmte Stufe aktivieren.

 Wenn Sie Caching aktivieren, müssen Sie eine Cache-Kapazität auswählen. Im Allgemeinen bietet eine größere Kapazität eine bessere Leistung, kostet aber auch mehr. Informationen zu den unterstützten Cachegrößen finden Sie [cacheClusterSize](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateStage.html#apigw-CreateStage-request-cacheClusterSize)in der *API Gateway API Reference*.

 API Gateway ermöglicht das Caching durch die Erstellung einer dedizierten Cache-Instance. Dieser Vorgang kann bis zu 4 Minuten dauern. 

API Gateway ändert die Caching-Kapazität durch Löschen der vorhandenen Cache-Instance und Erstellen einen neuen mit einer geänderten Kapazität. Alle Daten im Cache werden gelöscht. 

**Anmerkung**  
Die Cache-Kapazität wirkt sich auf die CPU- und Netzwerkbandbreite der Cache-Instance aus. Infolgedessen kann sich die Cache-Kapazität auf die Performance Ihres Caches auswirken.   
API Gateway empfiehlt, dass Sie einen 10-Minuten-Belastungstest durchführen, um zu überprüfen, ob Ihre Cache-Kapazität für Ihre Arbeitslast geeignet ist. Stellen Sie sicher, dass der Verkehr während des Lasttests den Produktionsverkehr widerspiegelt. Dazu gehören zum Beispiel Ramp Up, konstanter Verkehr und Verkehrsspitzen. Der Lasttest sollte Antworten enthalten, die aus dem Cache bereitgestellt werden können, sowie eindeutige Antworten, die dem Cache Elemente hinzufügen. Überwachen Sie die Latenz-, 4xx-, 5xx-, Cache-Hit- und Cache-Fehl-Metriken während des Belastungstests. Passen Sie Ihre Cache-Kapazität basierend auf diesen Metriken nach Bedarf an. Weitere Informationen zu Lasttests finden Sie unter [Wie wähle ich die beste Kapazität für den API-Gateway-Cache aus, um zu vermeiden, dass ein Ratenlimit erreicht wird?](https://repost.aws/knowledge-center/api-gateway-cache-capacity).

------
#### [ AWS-Managementkonsole ]

 In der API-Gateway-Konsole konfigurieren Sie das Caching auf der **Stages**-Seite. Sie stellen den Stage-Cache bereit und legen eine Standard-Cache-Einstellung auf Methodenebene fest. Wenn Sie den Standard-Cache auf Methodenebene aktivieren, wird die Zwischenspeicherung auf Methodenebene für alle `GET`-Methoden der Stufe aktiviert, es sei denn, es wurde eine Methodenüberschreibung konfiguriert. Alle zusätzlichen `GET`-Methoden, die Sie in dieser Stufe bereitstellen, verfügen über einen Cache auf Methodenebene. Sie können Methodenüberschreibungen verwenden, um die Caching-Einstellungen auf Methodenebene für bestimmte Methoden Ihrer Stufe zu konfigurieren. Weitere Informationen zu Methodenüberschreibungen finden Sie unter [Caching auf API-Gateway-Stufenebene für das Caching auf Methodenebene überschreiben](#override-api-gateway-stage-cache-for-method-cache).

**So konfigurieren Sie API-Caching für eine bestimmte Stufe:**

1. Melden Sie sich bei der API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigatewayan](https://console.aws.amazon.com/apigateway).

1. Wählen Sie **Stages**.

1. Wählen Sie in der API-Liste **Stages** den Namen der Stufe aus.

1. Wählen Sie im Abschnitt **Stage details** (Stufendetails) die Option **Edit** (Bearbeiten) aus.

1. Aktivieren Sie unter **Zusätzliche Einstellungen** aktivieren Sie **API-Cache bereitstellen** für Zugriff auf **Cache-Einstellungen**.

   Dadurch wird ein Cache-Cluster für Ihre Stufe bereitgestellt.

1. Aktivieren Sie **Standard-Caching auf Methodenebene** um für die Ebene Caching zuzulassen.

   Dadurch wird das Caching auf Methodenebene für alle `GET`-Methoden dieser Stufe aktiviert. Alle zusätzlichen `GET`-Methoden, die Sie in dieser Stufe bereitstellen, werden dann über einen Cache auf Methodenebene verfügen. 
**Anmerkung**  
Wenn bereits eine Einstellung für einen Cache auf Methodenebene vorhanden ist, wirkt sich eine Änderung des Standard-Cache auf Methodenebene nicht auf diese Einstellung aus.  
![\[Aktivieren Sie den Provision-API-Cache und den Standard-Cache auf Methodenebene.\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/api-caching-stage-flow.png)

1. Wählen Sie **Änderungen speichern ** aus.

------
#### [ AWS CLI ]

Der folgende [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html)-Befehl aktualisiert eine Stufe, um einen Cache bereitzustellen, und aktiviert das Methoden-Caching für alle `GET`-Methoden Ihrer Stufe.

```
aws apigateway update-stage \
    --rest-api-id a1b2c3 \
    --stage-name 'prod' \
    --patch-operations file://patch.json
```

Der Inhalt von `patch.json` ist wie folgt:

```
[
     {
          "op": "replace",
          "path": "/cacheClusterEnabled",
          "value": "true"
     },
     {
          "op": "replace",
          "path": "/cacheClusterSize",
          "value": "0.5"
     },
     {
        "op": "replace",
        "path": "/*/*/caching/enabled",
        "value": "true"
     }
]
```

**Anmerkung**  
Wenn bereits eine Einstellung für einen Cache auf Methodenebene vorhanden ist, wirkt sich eine Änderung des Standard-Cache auf Methodenebene nicht auf diese Einstellung aus.

------

**Anmerkung**  
 Das API Gateway benötigt etwa 4 Minuten für das Erstellen und Löschen eines Caches.   
Bei Erstellung eines Cache springt der **Cache-Cluster**-Wert von `Create in progress` auf `Active`. Nach vollständiger Löschung des Cache springt der **Cache-Cluster**-Wert von `Delete in progress` auf `Inactive`.  
Wenn Sie das Caching auf Methodenebene für alle Methoden in Ihrer Stufe aktivieren, springt der Wert für **Standard-Cache auf Methodenebene** auf `Active`. Wenn Sie das Caching auf Methodenebene für alle Methoden in Ihrer Stufe deaktivieren, springt der Wert für **Standard-Cache auf Methodenebene** auf `Inactive`. Wenn bereits eine Einstellung für Standard-Cache auf Methodenebene vorhanden ist, wirkt sich ein Statusänderung des Cache nicht auf diese Einstellung aus. 

Wenn Sie das Caching in den **Cache-Einstellungen** einer Stufe aktivieren, werden nur `GET`-Methoden zwischengespeichert. Um die Sicherheit und Verfügbarkeit Ihrer API zu gewährleisten, empfehlen wir Ihnen, diese Einstellung nicht zu ändern. Sie können das Caching aber auch für andere Methoden [ aktivieren, indem Sie die Methodeneinstellungen überschreiben](#override-api-gateway-stage-cache-for-method-cache).

 Wenn Sie sich vergewissern möchten, ob die Zwischenspeicherung wie erwartet funktioniert, haben Sie zwei allgemeine Optionen: 
+  Untersuchen Sie die CloudWatch Metriken von **CacheHitCount**und **CacheMissCount**für Ihre API und Stage. 
+  Setzen Sie einen Zeitstempel in der Antwort. 

**Anmerkung**  
Verwenden Sie nicht den `X-Cache` Header aus der CloudFront Antwort, um festzustellen, ob Ihre API von Ihrer API Gateway Gateway-Cache-Instance bedient wird.

## Caching auf API-Gateway-Stufenebene für das Caching auf Methodenebene überschreiben
<a name="override-api-gateway-stage-cache-for-method-cache"></a>

Sie können Cache-Einstellungen auf Stufenebene überschreiben, indem Sie das Caching für eine bestimmte Methode aktivieren oder deaktivieren. Sie können außerdem auch den TTL-Zeitraum ändern oder die Verschlüsselung für zwischengespeicherte Antworten ein- oder ausschalten. 

Wenn Sie davon ausgehen, dass eine Methode sensible Daten in ihren Antworten erhält, verschlüsseln Sie Ihre Cache-Daten. Dies kann erforderlich sein, um verschiedene Compliance-Rahmenwerke einzuhalten. Weitere Informationen finden Sie unter [Amazon-API-Gateway-Steuerelemente](https://docs.aws.amazon.com/securityhub/latest/userguide/apigateway-controls.html) im *Benutzerhandbuch für AWS Security Hub *.

------
#### [ AWS-Managementkonsole ]

Wenn Sie die Einstellung für Standard-Caching auf Methodenebene in den **Stufendetails** ändern, hat dies keine Auswirkungen auf die Cache-Einstellungen auf Methodenebene, für die Überschreibungen konfiguriert sind.

Wenn Sie davon ausgehen, dass eine zwischengespeicherte Methode sensible Daten in ihren Antworten erhält, wählen Sie in den **Cache-Einstellungen** die Option **Encrypt cache data** aus.

**So konfigurieren Sie API-Caching für einzelne Methoden mithilfe der Konsole:**

1. Melden Sie sich bei der API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigatewayan](https://console.aws.amazon.com/apigateway).

1. Wählen Sie die API.

1. Wählen Sie **Stages**.

1. Erweitern Sie in der Liste **Stufen** für die API die Stufe, und wählen Sie eine Methode in der API aus.

1. Wählen Sie im Abschnitt **Methodenüberschreibungen** die Option **Bearbeiten** aus.

1. Aktivieren oder deaktivieren Sie im Abschnitt **Methodeneinstellungen** die Option **Methoden-Cache aktivieren** oder deaktivieren Sie die gewünschten Optionen.
**Anmerkung**  
Das Caching ist erst dann aktiv, wenn Sie einen Cache-Cluster für Ihre Stufe bereitstellen.

1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

Der folgende [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html)-Befehl deaktiviert den Cache nur für die `GET /pets` Methode:

```
aws apigateway update-stage /
    --rest-api-id a1b2c3 /
    --stage-name 'prod' /
    --patch-operations file://patch.json
```

Der Inhalt von `patch.json` ist wie folgt:

```
[{
        "op": "replace",
        "path": "/~1pets/GET/caching/enabled",
        "value": "false"
}]
```

------

## Verwenden der Methoden-/Integrationsparameter als Cache-Schlüssel, um zwischengespeicherte Antworten zu indizieren
<a name="enable-api-gateway-cache-keys"></a>

Sie können eine Methode oder Integrationsparameter als Cache-Schlüssel verwenden, um zwischengespeicherte Antworten zu indizieren. Dazu gehören benutzerdefinierte Header, URL-Pfade oder Abfragezeichenfolgen. Sie können ein paar oder alle dieser Parameter als Cache-Schlüssel festlegen - es muss jedoch mindestens ein Wert vorgegeben werden. Wenn ein Cache-Schlüssel vorhanden ist, speichert API Gateway die Antworten der einzelnen Schlüsselwerte separat im Cache; dasselbe geschieht wenn kein Cache-Schlüssel vorliegt.

**Anmerkung**  
Cache-Schlüssel sind beim Einrichten von Caching für eine Ressource erforderlich.

 Angenommen, Sie haben eine Anforderung im folgenden Format: 

```
GET /users?type=... HTTP/1.1
host: example.com
...
```

In dieser Anforderung kann `type` den Wert `admin` oder `regular` annehmen. Wenn Sie den `type`-Parameter als Teil des Cache-Schlüssels einbinden, werden die Antworten aus `GET /users?type=admin` getrennt von denen aus `GET /users?type=regular` zwischengespeichert. 

 Wenn eine Methode oder Integrationsanforderung mehr als einen Parameter annimmt, können Sie einige oder alle dieser Parameter einschließen, um den Cache-Schlüssel zu erstellen. Beispielsweise können Sie für die folgende Anforderung nur den `type`-Parameter in den Cache-Schlüssel einschließen, in der aufgelisteten Reihenfolge innerhalb eines TTL-Zeitraums: 

```
GET /users?type=admin&department=A HTTP/1.1
host: example.com
...
```

 Die Antwort von dieser Anforderung wird im Cache gespeichert und verwendet, um die folgende Anforderung zu bedienen: 

```
GET /users?type=admin&department=B HTTP/1.1
host: example.com
...
```

------
#### [ AWS-Managementkonsole ]

Um einen Methoden- oder Integrationsanforderungsparameter als Teil eines Cache-Schlüssels in die API Gateway-Konsole aufzunehmen, wählen Sie **Caching**, nachdem Sie den Parameter hinzugefügt haben. 

![\[Einschließen von Methoden- oder Integrationsparametern als Cache-Schlüssel, um eine zwischengespeicherte Antwort zu indizieren\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/api-caching-including-parameter-as-cache-key-new-console.png)


------
#### [ AWS CLI ]

Der folgende [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html)-Befehl erstellt eine `GET`-Methode und erfordert den Abfragezeichenfolgeparameter `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"
```

Der folgende [put-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration.html)-Befehl erstellt eine Integration für die `GET`-Methode mit einem HTTP-Endpunkt und gibt an, dass API Gateway den Methodenanforderungsparameter `type` zwischenspeichert:

```
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"
```

Um einen Integrationsanforderungsparameter für den API-Gateway-Cache festzulegen, verwenden Sie `integration.request.location.name` als Cache-Schlüsselparameter.

------

## API-Stufen-Cache in API Gateway leeren
<a name="flush-api-caching"></a>

Wenn API-Zwischenspeicherung aktiviert ist, können Sie den Cache Ihrer API-Stufe löschen, um sicherzustellen, dass die Clients Ihrer API die neuesten Antworten von Ihren Integrationsendpunkten erhalten.

------
#### [ AWS-Managementkonsole ]

**So leeren Sie den API-Stufen-Cache**

1. Melden Sie sich bei der API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigatewayan](https://console.aws.amazon.com/apigateway).

1. Wählen Sie eine API aus, die über eine Stufe mit einem Cache verfügt.

1. Wählen Sie zunächst im Hauptnavigationsbereich **Stufen** und anschließend Ihre Stufe mit einem Cache aus.

1. Wählen Sie das Menü **Stufenaktionen** und dann **Stage-Cache bereinigen** aus.

------
#### [ AWS CLI ]

Mit dem folgenden [flush-stage-cache](https://docs.aws.amazon.com/cli/latest/reference/apigateway/flush-stage-cache.html)Befehl wird der Stage-Cache geleert:

```
aws apigateway flush-stage-cache \
    --rest-api-id a1b2c3 \
    --stage-name prod
```

------

**Anmerkung**  
Nachdem der Cache gelöscht wurde, werden Antworten aus dem Integrationsendpunkt bedient, bis der Cache wieder aufgebaut ist. Während dieses Zeitraums kann sich die Anzahl der Anforderungen an den Integrationsendpunkt erhöhen. Dadurch kann sich die Gesamt-Latenz Ihrer API zeitweilig erhöhen. 

## API Gateway-Cache-Eintrag ungültig machen
<a name="invalidate-method-caching"></a>

Ein Client Ihrer API kann einen vorhandenen Cache-Eintrag entwerten und ihn vom Integrationsendpunkt für einzelne Anforderungen neu laden. Der Client muss eine Anforderung senden, die den Header `Cache-Control: max-age=0` enthält. Der Client erhält die Antwort direkt vom Integrationsendpunkt anstelle des Zwischenspeichers, wenn der Client hierfür eine entsprechende Berechtigung hat. Dies ersetzt den vorhandenen Cache-Eintrag durch die neue Antwort, die vom Integrationsendpunkt abgerufen wird. 

 Um einem Aufrufer eine Berechtigung zu erteilen, fügen Sie an die IAM-Ausführungsrolle für den Client eine Richtlinie im folgenden Format an.

**Anmerkung**  
Die kontoübergreifende Cache-Invalidierung wird nicht unterstützt.

------
#### [ 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"
            ]
        }
    ]
}
```

------

 Diese Richtlinie erlaubt es dem API Gateway-Ausführungsdienst, den Cache für Anfragen zur angegebenen Ressource (oder den angegebenen Ressourcen) ungültig zu machen. Um eine Gruppe zum Ziel gesetzter Ressourcen anzugeben, verwenden Sie ein Platzhalterzeichen (\$1) für `account-id`, `api-id` und andere Angaben im ARN-Wert von `Resource`. Weitere Informationen über das Festlegen von Berechtigungen für den API Gateway-Ausführungsdienst finden Sie unter [Zugriffskontrolle für eine API mit IAM-Berechtigungen](permissions.md). 

 Wenn sie keine `InvalidateCache`-Richtlinie angeben (oder das Kontrollkästchen **Autorisierung erforderlich** in der Konsole aktivieren), kann jeder beliebige Client den API-Zwischenspeicher entwerten. Wenn die meisten oder alle Clients den API-Cache entwerten, kann dies zu einer erheblichen Steigerung der Latenz Ihrer API führen. 

 Wenn die Richtlinie eingerichtet ist, wird das Caching aktiviert und eine Autorisierung ist erforderlich.

Sie können festlegen, wie API Gateway mit nicht autorisierten Anfragen umgehen soll, indem Sie aus den folgenden Optionen wählen:

**Anfrage mit HTTP-Statuscode 403 ablehnen**  
API Gateway gibt eine `403 Unauthorized`-Antwort zurück.  
 Geben Sie zum Einstellen dieser Option über die API ei `FAIL_WITH_403`.

**Cache-Control-Header ignorieren; Warnung im Antwort-Header hinzufügen**  
API Gateway verarbeitet die Anfrage und fügt im Antwort-Header eine Warnung hinzu.  
 Geben Sie zum Einstellen dieser Option über die API ei `SUCCEED_WITH_RESPONSE_HEADER`. 

**Cache-Control-Header ignorieren**  
API Gateway verarbeitet die Anfrage, fügt jedoch keine Warnung im Antwort-Header hinzu.  
 Geben Sie zum Einstellen dieser Option über die API ei `SUCCEED_WITHOUT_RESPONSE_HEADER`.

Sie können das Verhalten für nicht autorisierte Anfragen über die API-Gateway-Konsole oder die AWS CLI einstellen.

------
#### [ AWS-Managementkonsole ]

**So geben Sie an, wie nicht autorisierte Anfragen behandelt werden sollen**

1. Melden Sie sich bei der API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigatewayan](https://console.aws.amazon.com/apigateway).

1. Wählen Sie eine API aus, die über eine Stufe mit einem Cache verfügt.

1. Wählen Sie zunächst im Hauptnavigationsbereich **Stufen** und anschließend Ihre Stufe mit einem Cache aus.

1. Wählen Sie unter **Stufendetails** die Option **Bearbeiten** aus.

1. Wählen Sie unter **Bearbeitung nicht autorisierter Anfragen** eine Option aus.

1. Klicken Sie auf **Weiter**.

1. Überprüfen Sie Ihre Änderungen und klicken Sie dann auf **Änderungen speichern**.

------
#### [ AWS CLI ]

Der folgende [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html)-Befehl aktualisiert eine Stufe, sodass nicht autorisierte Anfragen mit einem HTTP-Statuscode 403 abgelehnt werden:

```
aws apigateway update-stage /
    --rest-api-id a1b2c3 /
    --stage-name 'prod' /
    --patch-operations 'op=replace,path=/*/*/caching/unauthorizedCacheControlHeaderStrategy,value="FAIL_WITH_403"'
```

------

## CloudFormation Beispiel für eine Phase mit einem Cache
<a name="cfn-cache-example"></a>

Die folgende CloudFormation Vorlage erstellt eine Beispiel-API, stellt einen `0.5` GB-Cache für die `Prod` Stufe bereit und aktiviert das Caching auf Methodenebene für alle Methoden. `GET`

**Wichtig**  
Caching wird basierend auf der von Ihnen ausgewählten Cache-Größe nach Stunden berechnet. Caching ist für das kostenlose AWS -Kontingent nicht zulässig. Weitere Informationen finden Sie unter [API-Gateway-Preise](https://aws.amazon.com/api-gateway/pricing/).

### CloudFormation Beispielvorlage
<a name="cfn-cache-example-code"></a>

```
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
```

# Payload-Komprimierung für REST APIs in API Gateway
<a name="api-gateway-gzip-compression-decompression"></a>

 API Gateway ermöglicht es Ihrem Client, über eine der [unterstützten Inhaltskodierungen](api-gateway-enable-compression.md#api-gateway-supported-content-encodings) Ihre API mit komprimierten Payloads aufzurufen. API Gateway unterstützt standardmäßig die Dekomprimierung der Methodenanforderungsnutzlast. Sie müssen Ihre API allerdings so konfigurieren, dass die Komprimierung der Methodenantwortnutzlast aktiviert wird. 

 Zum Aktivieren der Komprimierung für eine [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html) legen Sie für die Eigenschaft [https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#minimumCompressionSize) beim oder nach dem Erstellen der API eine nicht negative Ganzzahl zwischen 0 und 10485760 (10 M Bytes) fest. Zum Deaktivieren der Komprimierung in der API legen Sie `minimumCompressionSize` auf Null fest oder entfernen Sie die Eigenschaft. Sie können die Komprimierung für eine API aktivieren oder deaktivieren, indem Sie die API Gateway Gateway-Konsole AWS CLI, die oder die API Gateway Gateway-REST-API verwenden. 

Wenn Sie die Komprimierung auf eine Nutzlast jeder beliebigen Größe angewendet werden soll, legen Sie den Wert `minimumCompressionSize` auf Null fest. Durch die Komprimierung einer kleinen Datengröße kann sich jedoch die endgültige Datengröße erhöhen. Darüber hinaus kann die Komprimierung in API Gateway und die Dekomprimierung im Client die Gesamtlatenzzeit erhöhen und mehr Rechenzeit erfordern. Führen Sie Testläufe für Ihre API aus, um den optimalen Wert zu bestimmen.

Der Client kann eine API-Anfrage mit einer komprimierten Nutzlast und einem geeigneten `Content-Encoding`-Header für API Gateway senden, um geeignete Zuweisungsvorlagen zu komprimieren und anzuwenden, bevor die Anfrage dem Integrationsendpunkt übergeben wird. Nachdem die Komprimierung aktiviert und die API bereitgestellt wurde, kann der Client eine API-Antwort mit einer komprimierten Nutzlast empfangen, wenn ein geeigneter `Accept-Encoding`-Header in der Methodenanforderung angegeben ist. 

Wenn der Integrationsendpunkt nicht komprimierte JSON-Nutzlasten erwartet und zurückgibt, ist jede Zuweisungsvorlage, die für eine nicht komprimierte JSON-Nutzlast konfiguriert ist, für die komprimierte Nutzlast anwendbar. Für eine komprimierte Methodenanforderungsnutzlast dekomprimiert API Gateway die Nutzlast, wendet die Zuweisungsvorlage an und übergibt dem Integrationsendpunkt die zugewiesene Anfrage. Für eine nicht komprimierte Methodenanforderungsnutzlast wendet API Gateway die Zuweisungsvorlage an, komprimiert die zugewiesene Nutzlast und gibt die komprimierte Nutzlast an den Client zurück. 

**Topics**
+ [Nutzlastkomprimierung für eine API in API Gateway aktivieren](api-gateway-enable-compression.md)
+ [Aufrufen einer API-Methode mit einer komprimierten Nutzlast in API Gateway](api-gateway-make-request-with-compressed-payload.md)
+ [Empfangen einer API-Antwort mit einer komprimierten Nutzlast in API Gateway](api-gateway-receive-response-with-compressed-payload.md)

# Nutzlastkomprimierung für eine API in API Gateway aktivieren
<a name="api-gateway-enable-compression"></a>

Sie können die Komprimierung für eine API mithilfe der API Gateway Gateway-Konsole AWS CLI, des oder eines AWS SDK aktivieren.

Im Fall einer vorhandenen API müssen Sie nach der Aktivierung der Komprimierung die API bereitstellen, damit die Änderungen wirksam werden. Im Fall einer neuen API können Sie die API nach Abschluss der API-Einrichtung bereitstellen.

**Anmerkung**  
Die Inhaltskodierung mit der höchsten Priorität muss von API Gateway unterstützt werden. Wenn dies nicht der Fall ist, wird keine Komprimierung auf die Antwortnutzlast angewendet.

**Topics**
+ [Payload-Komprimierung für eine API über die API Gateway-Konsole aktivieren](#api-gateway-enable-compression-console)
+ [Aktivieren Sie die Payload-Komprimierung für eine API mithilfe von AWS CLI](#api-gateway-enable-compression-cli)
+ [Von API Gateway unterstützte Inhaltskodierungen](#api-gateway-supported-content-encodings)

## Payload-Komprimierung für eine API über die API Gateway-Konsole aktivieren
<a name="api-gateway-enable-compression-console"></a>

Im folgenden Verfahren wird beschrieben, wie Sie die Nutzlastkomprimierung für eine API aktivieren. 

**So aktivieren Sie die Payload-Komprimierung über die API Gateway-Konsole:**

1. Melden Sie sich bei der API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigatewayan](https://console.aws.amazon.com/apigateway).

1. Wählen Sie eine vorhandene API oder erstellen Sie eine neue.

1. Wählen Sie im Hauptnavigationsbereich **API-Einstellungen**. 

1. Wählen Sie im Abschnitt **API-Details** die Option **Bearbeiten** aus.

1. Aktivieren Sie die **Inhaltskodierung**, um die Nutzlast-Komprimierung zu aktivieren. Geben Sie einen Wert für die Mindestkomprimierungsgröße (in Byte) unter **Mindesttextgröße** ein. Um die Komprimierung zu deaktivieren, schalten Sie die Option **Inhaltskodierung** aus.

1. Wählen Sie **Änderungen speichern ** aus.

## Aktivieren Sie die Payload-Komprimierung für eine API mithilfe von AWS CLI
<a name="api-gateway-enable-compression-cli"></a>



Der folgende [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html)Befehl erstellt eine API mit Payload-Komprimierung:

```
aws apigateway create-rest-api \
    --name "My test API" \
    --minimum-compression-size 0
```

Der folgende [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html)Befehl aktiviert die Payload-Komprimierung für eine bestehende API:

```
aws apigateway update-rest-api \
    --rest-api-id 1234567890 \
    --patch-operations op=replace,path=/minimumCompressionSize,value=0
```

Die Eigenschaft `minimumCompressionSize` weist eine nicht negative ganze Zahl zwischen 0 und 10485760 (10 M Bytes) auf. Mit ihr wird die Komprimierung gemessen. Wenn die Nutzlastgröße kleiner als dieser Wert ist, wird die Komprimierung oder Dekomprimierung nicht auf die Nutzlast angewendet. Wenn er auf Null festgelegt ist, ist die Komprimierung für jede beliebige Nutzlastgröße erlaubt.

Der folgende [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html)Befehl deaktiviert die Payload-Komprimierung:

```
aws apigateway update-rest-api \
    --rest-api-id 1234567890 \
    --patch-operations op=replace,path=/minimumCompressionSize,value=
```

Sie können `value` auch auf eine leere Zeichenfolge `""` festlegen oder die Eigenschaft `value` im vorhergehenden Aufruf vollständig weglassen.

## Von API Gateway unterstützte Inhaltskodierungen
<a name="api-gateway-supported-content-encodings"></a>

API Gateway unterstützt die folgenden Inhaltskodierungen:
+ `deflate`
+ `gzip`
+ `identity`

API Gateway unterstützt auch das folgende `Accept-Encoding` Header-Format gemäß der Spezifikation [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`

# Aufrufen einer API-Methode mit einer komprimierten Nutzlast in API Gateway
<a name="api-gateway-make-request-with-compressed-payload"></a>

Um eine API-Anfrage mit einer komprimierten Nutzlast zu erstellen, muss der Client den `Content-Encoding`-Header mit einer der [unterstützten Inhaltscodierungen](api-gateway-enable-compression.md#api-gateway-supported-content-encodings) festlegen. 

Angenommen, Sie sind ein API-Client und möchten die PetStore API-Methode (`POST /pets`) aufrufen. Rufen Sie die Methode nicht mit der folgenden JSON-Ausgabe auf:

```
POST /pets
Host: {petstore-api-id}.execute-api.{region}.amazonaws.com
Content-Length: ...

{
  "type": "dog",
  "price": 249.99
}
```

Stattdessen können Sie die Methode mit der gleichen Nutzlast aufrufen, die mit der GZIP-Codierung komprimiert wird:

```
POST /pets
Host: {petstore-api-id}.execute-api.{region}.amazonaws.com
Content-Encoding:gzip
Content-Length: ...

���RPP*�,HU�RPJ�OW��e&���L,�,-y�j
```

Wenn API Gateway die Anfrage erhält, prüft es, ob die angegebene Inhaltskodierung unterstützt wird. Anschließend wird versucht, die Nutzlast mit der angegebenen Inhaltscodierung zu dekomprimieren. Wenn die Dekomprimierung erfolgreich ist, wird die Anforderung an den Integrationsendpunkt gesendet. Wenn die angegebene Kodierung nicht unterstützt wird oder der gelieferte Payload nicht mit der angegebenen Kodierung komprimiert ist, gibt API Gateway die `415 Unsupported Media Type`-Fehlerantwort zurück. Der Fehler wird nicht in CloudWatch Logs protokolliert, wenn er in der frühen Phase der Dekomprimierung auftritt, bevor Ihre API und Ihre Phase identifiziert wurden. 

# Empfangen einer API-Antwort mit einer komprimierten Nutzlast in API Gateway
<a name="api-gateway-receive-response-with-compressed-payload"></a>

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.