

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.

# WebSocket APIs In API Gateway entwickeln
<a name="websocket-api-develop"></a>

Dieser Abschnitt enthält Einzelheiten zu den API Gateway Gateway-Funktionen, die Sie bei der Entwicklung Ihres API Gateway benötigen APIs.

Während Sie Ihre API Gateway-API entwickeln, entscheiden Sie sich für eine Reihe von Merkmalen Ihrer API. Diese Eigenschaften hängen davon ab, wofür Ihre API verwendet werden soll. So könnte es beispielsweise sein, dass Sie es nur bestimmten Clients gestatten möchten, die API aufzurufen. Vielleicht soll die API aber auch für alle verfügbar sein. Vielleicht benötigen Sie einen API-Aufruf, um eine Lambda-Funktion auszuführen, eine Datenbankabfrage durchzuführen oder eine Anwendung aufzurufen.

**Topics**
+ [WebSocket APIs Im API Gateway erstellen](apigateway-websocket-api-create-empty-api.md)
+ [IP-Adresstypen für WebSocket-APIs im API Gateway](websocket-api-ip-address-type.md)
+ [Routen für WebSocket APIs im API Gateway erstellen](websocket-api-develop-routes.md)
+ [Steuern und verwalten Sie den Zugriff WebSocket APIs auf das API Gateway](apigateway-websocket-api-control-access.md)
+ [Integrationen für das WebSocket APIs API Gateway](apigateway-websocket-api-integrations.md)
+ [Validierung für WebSocket APIs im API Gateway anfordern](websocket-api-request-validation.md)
+ [Datentransformationen für WebSocket APIs im API Gateway](websocket-api-data-transformations.md)
+ [Binäre Medientypen für WebSocket-APIs in API Gateway](websocket-api-develop-binary-media-types.md)
+ [Aufrufen WebSocket APIs](apigateway-how-to-call-websocket-api.md)

# WebSocket APIs Im API Gateway erstellen
<a name="apigateway-websocket-api-create-empty-api"></a>

Sie können eine WebSocket API in der API Gateway Gateway-Konsole erstellen, indem Sie den Befehl AWS CLI [create-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html) oder den `CreateApi` Befehl in einem AWS SDK verwenden. Die folgenden Verfahren zeigen, wie Sie eine neue WebSocket API erstellen.

**Anmerkung**  
WebSocket APIs unterstützt nur TLS 1.2 und TLS 1.3. Frühere TLS-Versionen werden nicht unterstützt.

## Erstellen Sie eine WebSocket API mithilfe von AWS CLI Befehlen
<a name="apigateway-websocket-api-create-using-awscli"></a>

Der folgende [create-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html)-Befehl erstellt eine API mit dem Routen-Auswahlausdruck `$request.body.action`:

```
aws apigatewayv2 --region us-east-1 create-api --name "myWebSocketApi3" --protocol-type WEBSOCKET --route-selection-expression '$request.body.action'
```

Die Ausgabe sollte wie folgt aussehen:

```
{
    "ApiKeySelectionExpression": "$request.header.x-api-key",
    "Name": "myWebSocketApi3",
    "CreatedDate": "2018-11-15T06:23:51Z",
    "ProtocolType": "WEBSOCKET",
    "RouteSelectionExpression": "'$request.body.action'",
    "ApiId": "aabbccddee"
}
```

## Erstellen Sie eine WebSocket API mit der API Gateway Gateway-Konsole
<a name="apigateway-websocket-api-create-using-console"></a>

Sie können eine WebSocket API in der Konsole erstellen, indem Sie das WebSocket Protokoll auswählen und der API einen Namen geben.

**Wichtig**  
Sobald Sie die API erstellt haben, können Sie das für sie ausgewählte Protokoll nicht mehr ändern. Es gibt keine Möglichkeit, eine WebSocket API in eine REST-API umzuwandeln oder umgekehrt.

**So erstellen Sie eine WebSocket API mit der API Gateway Gateway-Konsole**

1. Melden Sie sich bei der API Gateway-Konsole an und wählen Sie **Create API (API erstellen)**.

1. Wählen Sie unter **WebSocket API** die Option **Build** aus. Es werden nur regionale Endpunkte unterstützt.

1. Geben Sie unter **API-Name** den Namen Ihrer API ein.

1. Geben Sie unter **Ausdruck für die Routenauswahl** einen Wert ein. Beispiel, `$request.body.action`. 

   Weitere Informationen zu Routen-Auswahlausdrücken finden Sie unter [Routen-Auswahlausdrücke](websocket-api-develop-routes.md#apigateway-websocket-api-route-selection-expressions).

1. Führen Sie eine der folgenden Aktionen aus:
   + Wählen Sie **Leere API erstellen** aus, wenn Sie eine API ohne Routen erstellen möchten.
   + Klicken Sie auf **Weiter**, um Ihrer API Routen anzuhängen.

   Sie können Routen anhängen, nachdem Sie Ihre API erstellt haben.

# IP-Adresstypen für WebSocket-APIs im API Gateway
<a name="websocket-api-ip-address-type"></a>

Beim Erstellen einer API geben Sie den Typ der IP-Adressen an, die Ihre API aufrufen dürfen. Sie können IPv4 auswählen, um IPv4-Adressen für den Aufruf Ihrer API zuzulassen, oder Sie können Dualstack auswählen, um sowohl IPv4- als auch IPv6-Adressen zuzulassen. Wir empfehlen, den IP-Adresstyp auf Dualstack zu setzen, um Engpässe im IP-Adressraum zu vermeiden und Ihre Sicherheitsposition zu verbessern. Weitere Informationen zu den Vorteilen eines Dualstack-IP-Adresstyps finden Sie unter [IPv6 in AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).

## Überlegungen zu IP-Adresstypen
<a name="websocket-api-ip-address-type-considerations"></a>

Die folgenden Überlegungen können Ihre Verwendung von IP-Adresstypen beeinflussen:
+ Der Standard-IP-Adresstyp für alle WebSocket-APIs ist IPv4.
+ Wenn Sie den IP-Adresstyp einer bestehende API von IPv4 in Dualstack ändern, stellen Sie sicher, dass alle Richtlinien, die den Zugriff auf Ihre APIs steuern, aktualisiert wurden, um IPv6-Aufrufe zu berücksichtigen. Wenn Sie den IP-Adresstyp ändern, wird die Änderung sofort wirksam.
+ Ihre API kann einem benutzerdefinierten Domainnamen mit einem anderen IP-Adresstyp als Ihre API zugewiesen werden. Wenn Sie Ihren Standard-API-Endpunkt deaktivieren, kann dies die Art und Weise beeinflussen, wie Aufrufer Ihre API aufrufen können.

## Ändern des IP-Adresstyps einer WebSocket-API
<a name="websocket-api-ip-address-type-change"></a>

Sie können den IP-Adresstyp ändern, indem Sie die API-Konfiguration aktualisieren. Dies ist über die AWS-Managementkonsole, die AWS CLI, CloudFormation oder ein AWS SDK möglich. Wenn Sie den IP-Adresstyp der API ändern, müssen Sie Ihre API nicht erneut bereitstellen, damit die Änderungen wirksam werden. 

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

**So ändern Sie den IP-Adresstypen einer WebSocket-API**

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

1. Wählen Sie eine WebSocket-API.

1. Wählen Sie **API-Einstellungen** und anschließend **Bearbeiten** aus.

1. Wählen Sie unter „IP-Adresstyp“ entweder **IPv4** oder **Dualstack** aus.

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

   Die Änderung der API-Konfiguration wird sofort wirksam.

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

Der folgende [update-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-api.html)-Befehl aktualisiert eine API, sodass sie den IP-Adresstyp Dualstack verwendet:

```
aws apigatewayv2 update-api \
    --api-id abcd1234 \
    --ip-address-type dualstack
```

Die Ausgabe sieht wie folgt aus:

```
{
    "ApiEndpoint": "https://abcd1234.execute-api.us-east-1.amazonaws.com",
    "ApiId": "abcd1234",
    "ApiKeySelectionExpression": "$request.header.x-api-key",
    "CreatedDate": "2025-02-04T22:20:20+00:00",
    "DisableExecuteApiEndpoint": false,
    "Name": "My-WebSocket-API",
    "ProtocolType": "WEBSOCKET",
    "RouteSelectionExpression": "$request.method $request.path",
    "Tags": {},
    "NotificationUris": [],
    "IpAddressType": "dualstack"
}
```

------

# Routen für WebSocket APIs im API Gateway erstellen
<a name="websocket-api-develop-routes"></a>

In Ihrer WebSocket API werden eingehende JSON-Nachrichten auf der Grundlage von Routen, die Sie konfigurieren, an Backend-Integrationen weitergeleitet. (Nicht-JSON-Nachrichten werden an eine von Ihnen konfigurierte `$default`-Route weitergeleitet.)

Eine *Route* umfasst einen *Routenschlüssel*. Dabei handelt es sich um den Wert, der bei der Auswertung eines *Routen-Auswahlausdrucks* erwartet wird. Das `routeSelectionExpression` ist ein auf API-Ebene definiertes Attribut. Es gibt eine JSON-Eigenschaft an, von der erwartet wird, dass sie in der Nachricht-Nutzlast vorhanden ist. Weitere Informationen zu Routen-Auswahlausdrücken finden Sie unter [Routen-Auswahlausdrücke](#apigateway-websocket-api-route-selection-expressions).

Beispiel: Wenn Ihre JSON-Nachrichten eine `action`-Eigenschaft enthalten und Sie basierend auf dieser Eigenschaft verschiedene Aktionen durchführen möchten, könnte Ihr Routen-Auswahlausdruck `${request.body.action}` lauten. Ihre Routing-Tabelle würde in diesem Fall angeben, welche Aktion ausgeführt werden soll, indem der Wert der `action`-Eigenschaft gegen die benutzerdefinierten Routenschlüssel-Werte abgeglichen wird, die Sie in der Tabelle definiert haben.

Es gibt drei vordefinierte Routen, die verwendet werden können: `$connect`, `$disconnect` und `$default`. Darüber hinaus können Sie benutzerdefinierte Routen erstellen.
+ API Gateway ruft die `$connect` Route auf, wenn eine persistente Verbindung zwischen dem Client und einer WebSocket API initiiert wird.
+ API Gateway ruft die `$disconnect`-Route auf, wenn der Client oder der Server die Verbindung mit der API unterbricht.
+ API Gateway ruft eine benutzerdefinierte Route auf, wenn nach der Auswertung des Routen-Auswahlausdrucks im Hinblick auf die Nachricht eine übereinstimmende Route gefunden wird. Die Übereinstimmung bestimmt, welche Integration aufgerufen wird.
+ API Gateway ruft die Route `$default` auf, wenn der Routen-Auswahlausdruck nicht im Hinblick auf die Nachricht ausgewertet werden kann oder wenn keine übereinstimmende Route gefunden wird.

## Routen-Auswahlausdrücke
<a name="apigateway-websocket-api-route-selection-expressions"></a>

Ein *Routen-Auswahlausdruck* wird ausgewertet, wenn der Service die Route auswählt, der eine eingehende Nachricht folgen soll. Der Service verwendet die Route, deren `routeKey` genau dem ausgewerteten Wert entspricht. Wenn bei fehlender Übereinstimmung eine Route mit dem Routenschlüssel `$default` vorhanden ist, wird diese Route ausgewählt. Wenn keine Routen dem ausgewählten Wert entsprechen und keine `$default`-Route vorhanden ist, gibt der Service einen Fehler zurück. Für WebSocket -based APIs sollte der Ausdruck die folgende Form haben`$request.body.{path_to_body_element}`.

Angenommen, Sie senden die folgende JSON-Nachricht:

```
{
    "service" : "chat",
    "action" : "join",
    "data" : {
        "room" : "room1234"
   }
}
```

Möglicherweise möchten Sie das Verhalten Ihrer API basierend auf der Eigenschaft `action` auswählen. In diesem Fall könnten Sie den folgenden Routen-Auswahlausdruck definieren:

```
$request.body.action
```

`request.body`Bezieht sich in diesem Beispiel auf die JSON-Nutzlast Ihrer Nachricht und `.action` ist ein [JSONPath](https://goessner.net/articles/JsonPath/)Ausdruck. Sie können nach `request.body` einen beliebigen JSON-Pfad-Ausdruck verwenden. Denken Sie aber daran, dass das Ergebnis in Text umgewandelt wird. Wenn Ihr JSONPath Ausdruck beispielsweise ein Array mit zwei Elementen zurückgibt, wird dieses als Zeichenfolge `"[item1, item2]"` dargestellt. Aus diesem Grund ist es sinnvoll, dass Ihr Ausdruck auf einen Wert und nicht auf ein Array oder Objekt ausgewertet wird.

Sie können einfach einen statischen Wert oder auch mehrere Variablen verwenden. In der folgenden Tabelle werden Beispiele und deren im Hinblick auf die vorhergehende Nutzlast ausgewerteten Ergebnisse gezeigt.


| Ausdruck | Ausgewertetes Ergebnis | Beschreibung | 
| --- | --- | --- | 
| \$1request.body.action | join | Eine entpackte Variable | 
| \$1\$1request.body.action\$1 | join | Eine verpackte Variable | 
| \$1\$1request.body.service\$1/\$1\$1request.body.action\$1 | chat/join | Mehrere Variablen mit statischen Werten | 
| \$1\$1request.body.action\$1-\$1\$1request.body.invalidPath\$1  | join- | Wenn der nicht gefunden JSONPath wird, wird die Variable als „“ aufgelöst. | 
| action | action | Statischer Wert | 
| \$1\$1default | \$1default | Statischer Wert | 

Das ausgewertete Ergebnis wird zum Auffinden der Route verwendet. Wenn eine Route mit einem übereinstimmenden Routenschlüssel vorhanden ist, wird die Route zur Verarbeitung der Nachricht ausgewählt. Wenn keine passende Route gefunden wird, versucht API Gateway, die `$default`-Route zu finden, falls verfügbar. Wenn die `$default`-Route nicht definiert ist, gibt API Gateway einen Fehler zurück.

## Routen für eine WebSocket API in API Gateway einrichten
<a name="apigateway-websocket-api-routes"></a>

Wenn Sie zum ersten Mal eine neue WebSocket API erstellen, gibt es drei vordefinierte Routen: `$connect``$disconnect`, und`$default`. Sie können sie mithilfe der Konsole, der API oder erstellen AWS CLI. Auf Wunsch können Sie benutzerdefinierte Routen erstellen. Weitere Informationen finden Sie unter [Überblick über WebSocket APIs in API Gateway](apigateway-websocket-api-overview.md).

**Anmerkung**  
In der CLI ist es möglich, Routen vor oder nach dem Erstellen von Integrationen zu erstellen. Auch können Sie dieselbe Integration für mehrere Routen wiederverwenden.

### Route mit der API Gateway-Konsole erstellen
<a name="apigateway-websocket-api-route-using-console"></a>

**So erstellen Sie eine Route über die API Gateway-Konsole:**

1. Melden Sie sich bei der API Gateway-Konsole an, wählen Sie die API und wählen Sie **Routes (Routen)**.

1. Wählen Sie **Create route** (Route erstellen) aus.

1. Geben Sie bei **Route key** (Routenschlüssel) den Schlüsselnamen ein. Sie können die vordefinierten Routen (`$connect`, `$disconnect` und `$default`) oder eine benutzerdefinierte Route erstellen.
**Anmerkung**  
Wenn Sie eine benutzerdefinierte Route erstellen, verwenden Sie nicht das `$`-Präfix im Routenschlüsselnamen. Dieses Präfix ist für vordefinierte Routen reserviert.

1. Wählen und konfigurieren Sie den Integrationstyp für die Route. Weitere Informationen finden Sie unter [Richten Sie mit der WebSocket API Gateway-Konsole eine API-Integrationsanfrage ein](apigateway-websocket-api-integration-requests.md#apigateway-websocket-api-integration-request-using-console).

### Erstellen Sie eine Route mit dem AWS CLI
<a name="apigateway-websocket-api-route-using-awscli"></a>

Der folgende [create-route](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-route.html)-Befehl erstellt eine Route:

```
aws apigatewayv2 --region us-east-1 create-route --api-id aabbccddee --route-key $default
```

Die Ausgabe sieht wie folgt aus:

```
{
    "ApiKeyRequired": false,
    "AuthorizationType": "NONE",
    "RouteKey": "$default",
    "RouteId": "1122334"
}
```

### Angeben der Routenanforderungs-Einstellungen für `$connect`
<a name="apigateway-websocket-api-route-request-connect"></a>

Wenn Sie die `$connect`-Route für Ihre API einrichten, sind die folgenden optionalen Einstellungen verfügbar, um die Autorisierung für Ihre API zu ermöglichen. Weitere Informationen finden Sie unter [Die Route `$connect`](apigateway-websocket-api-route-keys-connect-disconnect.md#apigateway-websocket-api-routes-about-connect).
+ **Authorization (Autorisierung)**: Wenn keine Autorisierung erforderlich ist, können Sie `NONE` angeben. Geben Sie andernfalls Folgendes ein: 
  + `AWS_IAM`um den Zugriff auf Ihre API mithilfe von AWS Standard-IAM-Richtlinien zu kontrollieren. 
  + `CUSTOM`, um die Autorisierung für eine API durch Angabe einer zuvor von Ihnen erstellten Lambda-Genehmigerfunktion zu implementieren. Der Autorisierer kann sich in Ihrem eigenen AWS Konto oder einem anderen Konto befinden. AWS Weitere Informationen über Lambda-Genehmiger finden Sie unter [API Gateway-Lambda-Genehmiger verwenden](apigateway-use-lambda-authorizer.md).
**Anmerkung**  
In der API Gateway-Konsole ist die Einstellung `CUSTOM` erst sichtbar, nachdem Sie eine Genehmigerfunktion wie unter [Lambda-Genehmiger konfigurieren (Konsole)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-with-console) beschrieben eingerichtet haben.
**Wichtig**  
Die Einstellung von **Authorization (Autorisierung)** wird auf die gesamte API angewendet, nicht nur auf die `$connect`-Route. Die `$connect`-Route schützt die übrigen Routen, da sie für jede Verbindung aufgerufen wird.
+ **API-Schlüssel erforderlich**: Sie können für die `$connect`-Route einer API optional einen API-Schlüssel verlangen. Sie können API-Schlüssel zusammen mit Nutzungsplänen verwenden, um den Zugriff auf Ihre zu kontrollieren und zu verfolgen. APIs Weitere Informationen finden Sie unter [Nutzungspläne und API-Schlüssel für REST APIs in API Gateway](api-gateway-api-usage-plans.md).

### `$connect`-Routenanforderung über die API Gateway-Konsole einrichten
<a name="apigateway-websocket-api-connect-route-request-using-console"></a>

So richten Sie die `$connect` Routenanforderung für eine WebSocket API mithilfe der API-Gateway-Konsole ein:

1. Melden Sie sich bei der API Gateway-Konsole an, wählen Sie die API und wählen Sie **Routes (Routen)**.

1. Wählen Sie unter **Routes** (Routen) `$connect` aus oder erstellen Sie eine `$connect`-Route, indem Sie wie folgt vorgehen [Route mit der API Gateway-Konsole erstellen](#apigateway-websocket-api-route-using-console).

1. Wählen Sie im Abschnitt **Route request settings** (Einstellungen der Routenanforderung) die Option **Edit** (Bearbeiten) aus.

1. Wählen Sie für **Authorization** (Autorisierung) einen Autorisierungstyp aus.

1. Um eine API für die `$connect`-Route anzufordern, wählen Sie **Require API key** (API-Schlüssel erforderlich) aus.

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

# Richten Sie Routenantworten für WebSocket APIs in API Gateway ein
<a name="apigateway-websocket-api-route-response"></a>

WebSocket Routen können für bidirektionale oder unidirektionale Kommunikation konfiguriert werden. API-Gateway übergibt die Backend-Antwort nicht über die Routenantwort, es sei denn, Sie haben eine Routenantwort eingerichtet. 

**Anmerkung**  
Sie können nur die `$default` Routenantwort für definieren. WebSocket APIs Sie können eine Integrationsantwort verwenden, um die Antwort von einem Backend-Service zu manipulieren. Weitere Informationen finden Sie unter [Übersicht über Integrationsantworten](apigateway-websocket-api-integration-responses.md#apigateway-websocket-api-integration-response-overview). 

Sie können Routenantworten und Antwortauswahlausdrücke mithilfe der API Gateway Gateway-Konsole oder des AWS CLI oder eines AWS SDK konfigurieren. 

Weitere Informationen über Routenantwort-Auswahlausdrücke finden Sie unter [Routenantwort-Auswahlausdrücke](apigateway-websocket-api-selection-expressions.md#apigateway-websocket-api-route-response-selection-expressions).

**Topics**
+ [Routenantwort mit der API Gateway-Konsole einrichten](#apigateway-websocket-api-route-response-using-console)
+ [Richten Sie eine Routenantwort ein, indem Sie AWS CLI](#apigateway-websocket-api-route-response-using-awscli)

## Routenantwort mit der API Gateway-Konsole einrichten
<a name="apigateway-websocket-api-route-response-using-console"></a>

Nachdem Sie eine WebSocket API erstellt und eine Proxy-Lambda-Funktion an die Standardroute angehängt haben, können Sie die Routenantwort mit der API Gateway Gateway-Konsole einrichten:

1. Melden Sie sich bei der API Gateway Gateway-Konsole an und wählen Sie eine WebSocket API mit einer Proxy-Lambda-Funktionsintegration auf der `$default` Route aus.

1. Wählen Sie unter **Routes** (Routen) die `$default`-Route aus.

1. Wählen Sie **Enable two-way communication** (Bidirektionale Kommunikation aktivieren). 

1. Klicken Sie auf **Deploy API**.

1. Stellen Sie Ihre API für eine Stufe bereit.

 Stellen Sie mit dem folgenden [wscat](https://www.npmjs.com/package/wscat)-Befehl eine Verbindung mit Ihrer API her. Mehr über `wscat` erfahren Sie unter [Wird verwendet`wscat`, um eine Verbindung zu einer WebSocket API herzustellen und Nachrichten an diese zu senden](apigateway-how-to-call-websocket-api-wscat.md). 

```
wscat -c wss://api-id.execute-api.us-east-2.amazonaws.com/test
```

 Drücken Sie die Eingabetaste, um die Standardroute aufzurufen. Der Hauptteil Ihrer Lambda-Funktion sollte zurückgegeben werden.

## Richten Sie eine Routenantwort ein, indem Sie AWS CLI
<a name="apigateway-websocket-api-route-response-using-awscli"></a>

Der folgende [create-route-response](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-route-response.html)Befehl erstellt eine Routenantwort für die `$default` Route. Sie können die API-ID und Routing-ID identifizieren, indem Sie die Befehle [get-apis](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/get-apis.html) und [get-routes](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/get-routes.html) verwenden.

```
aws apigatewayv2 create-route-response \
    --api-id aabbccddee \
    --route-id 1122334  \
    --route-response-key '$default'
```

Die Ausgabe sieht wie folgt aus:

```
{
    "RouteResponseId": "abcdef",
    "RouteResponseKey": "$default"
}
```

# Richten Sie eine `$connect` Route ein, für die ein WebSocket Unterprotokoll erforderlich ist
<a name="websocket-connect-route-subprotocol"></a>

Clients können das `Sec-WebSocket-Protocol` Feld verwenden, um während der Verbindung zu Ihrer WebSocket API ein [WebSocket Unterprotokoll](https://datatracker.ietf.org/doc/html/rfc6455#page-12) anzufordern. Sie können eine Integration für die `$connect`-Route einrichten, um Verbindungen nur zuzulassen, wenn ein Client ein von Ihrer API unterstütztes Unterprotokoll anfordert.

Die folgende Lambda-Beispielfunktion gibt den `Sec-WebSocket-Protocol`-Header an Clients zurück. Die Funktion stellt nur dann eine Verbindung zu Ihrer API her, wenn der Client das `myprotocol`-Unterprotokoll angibt.

Eine CloudFormation Vorlage, die diese Beispiel-API- und Lambda-Proxyintegration erstellt, finden Sie unter [samples/ws-subprotocol.zip](samples/ws-subprotocol.zip).

```
export const handler = async (event) => {
    if (event.headers != undefined) {
        const headers = toLowerCaseProperties(event.headers);
        
        if (headers['sec-websocket-protocol'] != undefined) {
            const subprotocolHeader = headers['sec-websocket-protocol'];
            const subprotocols = subprotocolHeader.split(',');
            
            if (subprotocols.indexOf('myprotocol') >= 0) {
                const response = {
                    statusCode: 200,
                    headers: {
                        "Sec-WebSocket-Protocol" : "myprotocol"
                    }
                };
                return response;
            }
        }
    }
    
    const response = {
        statusCode: 400
    };
        
    return response;
};

function toLowerCaseProperties(obj) {
    var wrapper = {};
    for (var key in obj) {
        wrapper[key.toLowerCase()] = obj[key];
    }
    return wrapper;
}
```

Sie können [https://www.npmjs.com/package/wscat](https://www.npmjs.com/package/wscat) verwenden, um zu testen, ob Ihre API Verbindungen nur zulässt, wenn ein Client ein von Ihrer API unterstütztes Unterprotokoll anfordert. Die folgenden Befehle verwenden das `-s`-Flag, um während der Verbindung Unterprotokolle anzugeben.

Mit dem folgenden Befehl wird versucht, eine Verbindung mit einem nicht unterstützten Unterprotokoll herzustellen. Da der Client das `chat1`-Unterprotokoll angegeben hat, gibt die Lambda-Integration einen 400-Fehler zurück und die Verbindung ist nicht erfolgreich.

```
wscat -c wss://api-id.execute-api.region.amazonaws.com/beta -s chat1
error: Unexpected server response: 400
```

Der folgende Befehl enthält ein unterstütztes Unterprotokoll in der Verbindungsanforderung. Die Lambda-Integration ermöglicht die Verbindung.

```
wscat -c wss://api-id.execute-api.region.amazonaws.com/beta -s chat1,myprotocol
connected (press CTRL+C to quit)
```

Weitere Informationen zum Aufrufen WebSocket APIs finden Sie unter. [Aufrufen WebSocket APIs](apigateway-how-to-call-websocket-api.md)

# Steuern und verwalten Sie den Zugriff WebSocket APIs auf das API Gateway
<a name="apigateway-websocket-api-control-access"></a>

API Gateway unterstützt mehrere Mechanismen zur Steuerung und Verwaltung des Zugriffs auf Ihre WebSocket API.

Sie können die folgenden Mechanismen für die Authentifizierung und Autorisierung verwenden:
+ ** AWS Standard-IAM-Rollen und -Richtlinien** bieten flexible und robuste Zugriffskontrollen. Mithilfe von IAM-Rollen und -Richtlinien können Sie steuern, wer Ihre APIs Rollen erstellen und verwalten darf und wer sie aufrufen kann. Weitere Informationen finden Sie unter [Steuern Sie den Zugriff auf WebSocket APIs mit IAM-Autorisierung](apigateway-websocket-control-access-iam.md).
+ **IAM-Tags** können zusammen mit IAM-Richtlinien verwendet werden, um den Zugriff zu steuern. Weitere Informationen finden Sie unter [Tags zur Steuerung des Zugriffs auf API Gateway-REST-API-Ressourcen verwenden](apigateway-tagging-iam-policy.md).
+ **Lambda-Autorisierer** sind Lambda-Funktionen, die den Zugriff auf kontrollieren. APIs Weitere Informationen finden Sie unter [Steuern Sie den Zugriff WebSocket APIs mit AWS Lambda REQUEST-Autorisierern](apigateway-websocket-api-lambda-auth.md).

Um Ihre Sicherheitslage zu verbessern, empfehlen wir Ihnen, auf allen Ihren Routen einen Autorisierer für die `$connect` Route zu konfigurieren. WebSocket APIs 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 *.

**Topics**
+ [Steuern Sie den Zugriff auf WebSocket APIs mit IAM-Autorisierung](apigateway-websocket-control-access-iam.md)
+ [Steuern Sie den Zugriff WebSocket APIs mit AWS Lambda REQUEST-Autorisierern](apigateway-websocket-api-lambda-auth.md)

# Steuern Sie den Zugriff auf WebSocket APIs mit IAM-Autorisierung
<a name="apigateway-websocket-control-access-iam"></a>

Die IAM-Autorisierung in WebSocket APIs ähnelt der für [REST APIs](api-gateway-control-access-using-iam-policies-to-invoke-api.md), mit den folgenden Ausnahmen:
+ Die Aktion `execute-api` unterstützt `ManageConnections` zusätzlich zu vorhandenen Aktionen (`Invoke`, `InvalidateCache`). `ManageConnections` steuert den Zugriff auf die API @connections.
+ WebSocket Routen verwenden ein anderes ARN-Format:

  ```
  arn:aws:execute-api:region:account-id:api-id/stage-name/route-key
  ```
+ Die `@connections` API verwendet dasselbe ARN-Format wie REST APIs:

  ```
  arn:aws:execute-api:region:account-id:api-id/stage-name/POST/@connections
  ```

**Wichtig**  
Wenn Sie die [IAM-Autorisierung](#apigateway-websocket-control-access-iam) verwenden, müssen Sie Anforderungen mit [Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html) signieren.

Sie könnten z. B. die folgende Richtlinie für den Client einrichten. Dieses Beispiel ermöglicht allen Benutzern das Senden einer Nachricht (`Invoke`) für alle Routen, außer für eine geheime Route in der Stufe `prod`, und hindert alle Benutzer am Senden einer Nachricht zurück an verbundene Clients (`ManageConnections`) für alle Stufen.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke"
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-1:111122223333:api-id/prod/*"
            ]
        },
        {
            "Effect": "Deny",
            "Action": [
                "execute-api:Invoke"
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-1:111122223333:api-id/prod/secret"
            ]
        },
        {
            "Effect": "Deny",
            "Action": [
                "execute-api:ManageConnections"
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-1:111122223333:api-id/*"
            ]
        }
    ]
}
```

------

# Steuern Sie den Zugriff WebSocket APIs mit AWS Lambda REQUEST-Autorisierern
<a name="apigateway-websocket-api-lambda-auth"></a>

Eine Lambda-Autorisierungsfunktion in WebSocket APIs ähnelt der für [REST APIs](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-lambda-function-create), mit den folgenden Ausnahmen:
+  Sie können für die `$connect`-Route nur eine Lambda-Genehmiger-Funktion verwenden. 
+ Sie können keine Pfadvariablen (`event.pathParameters`) verwenden, da der Pfad fest ist.
+ `event.methodArn` unterscheidet sich von seinem REST API-Äquivalent, da es über keine HTTP-Methode verfügt. Im Fall von `$connect` endet `methodArn` mit `"$connect"`:

  ```
  arn:aws:execute-api:region:account-id:api-id/stage-name/$connect
  ```
+ Die Kontextvariablen in unterscheiden `event.requestContext` sich von denen für REST. APIs

 Das folgende Beispiel zeigt eine Eingabe für einen `REQUEST` Autorisierer für eine WebSocket API:

```
{
    "type": "REQUEST",
    "methodArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/default/$connect",
    "headers": {
        "Connection": "upgrade",
        "content-length": "0",
        "HeaderAuth1": "headerValue1",
        "Host": "abcdef123.execute-api.us-east-1.amazonaws.com",
        "Sec-WebSocket-Extensions": "permessage-deflate; client_max_window_bits",
        "Sec-WebSocket-Key": "...",
        "Sec-WebSocket-Version": "13",
        "Upgrade": "websocket",
        "X-Amzn-Trace-Id": "...",
        "X-Forwarded-For": "...",
        "X-Forwarded-Port": "443",
        "X-Forwarded-Proto": "https"
    },
    "multiValueHeaders": {
        "Connection": [
            "upgrade"
        ],
        "content-length": [
            "0"
        ],
        "HeaderAuth1": [
            "headerValue1"
        ],
        "Host": [
            "abcdef123.execute-api.us-east-1.amazonaws.com"
        ],
        "Sec-WebSocket-Extensions": [
            "permessage-deflate; client_max_window_bits"
        ],
        "Sec-WebSocket-Key": [
            "..."
        ],
        "Sec-WebSocket-Version": [
            "13"
        ],
        "Upgrade": [
            "websocket"
        ],
        "X-Amzn-Trace-Id": [
            "..."
        ],
        "X-Forwarded-For": [
            "..."
        ],
        "X-Forwarded-Port": [
            "443"
        ],
        "X-Forwarded-Proto": [
            "https"
        ]
    },
    "queryStringParameters": {
        "QueryString1": "queryValue1"
    },
    "multiValueQueryStringParameters": {
        "QueryString1": [
            "queryValue1"
        ]
    },
    "stageVariables": {},
    "requestContext": {
        "routeKey": "$connect",
        "eventType": "CONNECT",
        "extendedRequestId": "...",
        "requestTime": "19/Jan/2023:21:13:26 +0000",
        "messageDirection": "IN",
        "stage": "default",
        "connectedAt": 1674162806344,
        "requestTimeEpoch": 1674162806345,
        "identity": {
            "sourceIp": "..."
        },
        "requestId": "...",
        "domainName": "abcdef123.execute-api.us-east-1.amazonaws.com",
        "connectionId": "...",
        "apiId": "abcdef123"
    }
}
```

Die folgende Lambda-Autorisierungsfunktion ist eine WebSocket Version der Lambda-Autorisierungsfunktion für REST in: APIs [Weitere Beispiele für Lambda-Genehmigerfunktionen](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-lambda-function-create)

------
#### [ Node.js ]

```
   // A simple REQUEST authorizer example to demonstrate how to use request 
   // parameters to allow or deny a request. In this example, a request is  
   // authorized if the client-supplied HeaderAuth1 header and QueryString1 query parameter
   // in the request context match the specified values of
   // of 'headerValue1' and 'queryValue1' respectively.
            export const handler = function(event, context, callback) {
    console.log('Received event:', JSON.stringify(event, null, 2));

   // Retrieve request parameters from the Lambda function input:
   var headers = event.headers;
   var queryStringParameters = event.queryStringParameters;
   var stageVariables = event.stageVariables;
   var requestContext = event.requestContext;
       
   // Parse the input for the parameter values
   var tmp = event.methodArn.split(':');
   var apiGatewayArnTmp = tmp[5].split('/');
   var awsAccountId = tmp[4];
   var region = tmp[3];
   var ApiId = apiGatewayArnTmp[0];
   var stage = apiGatewayArnTmp[1];
   var route = apiGatewayArnTmp[2];
       
   // Perform authorization to return the Allow policy for correct parameters and 
   // the 'Unauthorized' error, otherwise.
   var authResponse = {};
   var condition = {};
    condition.IpAddress = {};
    
   if (headers.HeaderAuth1 === "headerValue1"
       && queryStringParameters.QueryString1 === "queryValue1") {
        callback(null, generateAllow('me', event.methodArn));
    }  else {
        callback(null, generateDeny('me', event.methodArn)); 
    }
}
    
// Helper function to generate an IAM policy
var generatePolicy = function(principalId, effect, resource) {
   // Required output:
   var authResponse = {};
    authResponse.principalId = principalId;
   if (effect && resource) {
       var policyDocument = {};
        policyDocument.Version = '2012-10-17		 	 	 '; // default version
       policyDocument.Statement = [];
       var statementOne = {};
        statementOne.Action = 'execute-api:Invoke'; // default action
       statementOne.Effect = effect;
        statementOne.Resource = resource;
        policyDocument.Statement[0] = statementOne;
        authResponse.policyDocument = policyDocument;
    }
   // Optional output with custom properties of the String, Number or Boolean type.
   authResponse.context = {
       "stringKey": "stringval",
       "numberKey": 123,
       "booleanKey": true
    };
   return authResponse;
}
    
var generateAllow = function(principalId, resource) {
   return generatePolicy(principalId, 'Allow', resource);
}
    
var generateDeny = function(principalId, resource) {
   return generatePolicy(principalId, 'Deny', resource);
}
```

------
#### [ Python ]

```
# A simple REQUEST authorizer example to demonstrate how to use request
# parameters to allow or deny a request. In this example, a request is
# authorized if the client-supplied HeaderAuth1 header and QueryString1 query parameter
# in the request context match the specified values of
# of 'headerValue1' and 'queryValue1' respectively.

import json


def lambda_handler(event, context):
    print(event)

    # Retrieve request parameters from the Lambda function input:
    headers = event['headers']
    queryStringParameters = event['queryStringParameters']
    stageVariables = event['stageVariables']
    requestContext = event['requestContext']

    # Parse the input for the parameter values
    tmp = event['methodArn'].split(':')
    apiGatewayArnTmp = tmp[5].split('/')
    awsAccountId = tmp[4]
    region = tmp[3]
    ApiId = apiGatewayArnTmp[0]
    stage = apiGatewayArnTmp[1]
    route = apiGatewayArnTmp[2]

    # Perform authorization to return the Allow policy for correct parameters
    # and the 'Unauthorized' error, otherwise.

    authResponse = {}
    condition = {}
    condition['IpAddress'] = {}

    if (headers['HeaderAuth1'] ==
            "headerValue1" and queryStringParameters["QueryString1"] == "queryValue1"):
        response = generateAllow('me', event['methodArn'])
        print('authorized')
        return json.loads(response)
    else:
        response = generateDeny('me', event['methodArn'])
        print('unauthorized')
        return json.loads(response)

    # Help function to generate IAM policy


def generatePolicy(principalId, effect, resource):
    authResponse = {}
    authResponse['principalId'] = principalId
    if (effect and resource):
        policyDocument = {}
        policyDocument['Version'] = '2012-10-17		 	 	 '
        policyDocument['Statement'] = []
        statementOne = {}
        statementOne['Action'] = 'execute-api:Invoke'
        statementOne['Effect'] = effect
        statementOne['Resource'] = resource
        policyDocument['Statement'] = [statementOne]
        authResponse['policyDocument'] = policyDocument

    authResponse['context'] = {
        "stringKey": "stringval",
        "numberKey": 123,
        "booleanKey": True
    }

    authResponse_JSON = json.dumps(authResponse)

    return authResponse_JSON


def generateAllow(principalId, resource):
    return generatePolicy(principalId, 'Allow', resource)


def generateDeny(principalId, resource):
    return generatePolicy(principalId, 'Deny', resource)
```

------

[Gehen Sie genauso vor wie bei REST, um die vorherige Lambda-Funktion als `REQUEST` Autorisierungsfunktion für eine WebSocket API zu konfigurieren. APIs](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-with-console)

Um die `$connect`-Route für die Verwendung dieses Lambda-Genehmigers in der Konsole zu konfigurieren, wählen Sie die `$connect`-Route oder erstellen diese. Wählen Sie im Abschnitt **Route request settings** (Einstellungen der Routenanforderung) die Option **Edit** (Bearbeiten) aus. Wählen Sie im Dropdown-Menü **Authorization** (Autorisierung) Ihren Autorisierer aus und wählen Sie dann **Save changes** (Änderungen speichern) aus.

Zum Testen des Genehmigers müssen Sie eine neue Verbindung erstellen. Wenn der Genehmiger in `$connect` geändert wird, hat dies keine Auswirkungen auf den bereits verbundenen Client. Wenn Sie eine Verbindung zu Ihrer WebSocket API herstellen, müssen Sie Werte für alle konfigurierten Identitätsquellen angeben. Beispielsweise können Sie eine Verbindung durch Senden einer gültigen Abfragezeichenfolge und eines gültigen Headers unter Verwendung von `wscat` wie im folgenden Beispiel herstellen:

```
wscat -c 'wss://myapi.execute-api.us-east-1.amazonaws.com/beta?QueryString1=queryValue1' -H HeaderAuth1:headerValue1
```

Bei dem Versuch, ohne einen gültigen Identitätswert eine Verbindung herzustellen, erhalten Sie eine `401`-Antwort:

```
wscat -c wss://myapi.execute-api.us-east-1.amazonaws.com/beta
error: Unexpected server response: 401
```

# Integrationen für das WebSocket APIs API Gateway
<a name="apigateway-websocket-api-integrations"></a>

Nach dem Einrichten einer API-Route müssen Sie diese in einen Endpunkt im Backend integrieren. Ein Backend-Endpunkt wird auch als Integrationsendpunkt bezeichnet und kann eine Lambda-Funktion, ein HTTP-Endpunkt oder eine AWS Serviceaktion sein. Die API-Integration beinhaltet eine Integrationsanforderung und eine Integrationsantwort.

In diesem Abschnitt erfahren Sie, wie Sie Integrationsanfragen und Integrationsantworten für Ihre WebSocket API einrichten. 

**Topics**
+ [Richten Sie eine WebSocket API-Integrationsanfrage in API Gateway ein](apigateway-websocket-api-integration-requests.md)
+ [Richten Sie eine WebSocket API-Integrationsantwort in API Gateway ein](apigateway-websocket-api-integration-responses.md)

# Richten Sie eine WebSocket API-Integrationsanfrage in API Gateway ein
<a name="apigateway-websocket-api-integration-requests"></a>

Das Einrichten einer Integrationsanforderung umfasst die folgenden Schritte:
+ Auswählen eines Routenschlüssels zum Integrieren im Backend.
+ Angabe des aufzurufenden Backend-Endpunkts. WebSocket APIs unterstützt die folgenden Integrationstypen:
  + `AWS_PROXY`
  + `AWS`
  + `HTTP_PROXY`
  + `HTTP`
  + `MOCK`

  Weitere Informationen zu Integrationstypen finden Sie [IntegrationType](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid.html#apis-apiid-integrations-integrationid-prop-integration-integrationtype)in der API Gateway V2 REST API.
+ Konfigurieren, wie die Routenanforderungsdaten bei Bedarf in Integrationsanforderungsdaten konvertiert werden, durch Angabe einer oder mehrerer Anforderungsvorlagen.

## Richten Sie mit der WebSocket API Gateway-Konsole eine API-Integrationsanfrage ein
<a name="apigateway-websocket-api-integration-request-using-console"></a>

**So fügen Sie mithilfe der API-Gateway-Konsole eine Integrationsanfrage zu einer Route in einer WebSocket API hinzu**

1. Melden Sie sich bei der API Gateway-Konsole an, wählen Sie die API und wählen Sie **Routes (Routen)**.

1. Wählen Sie unter **Routes (Routen)** die Route aus.

1. Wählen Sie die Registerkarte **Integration request** (Integrationsanforderung) und dann im Abschnitt **Integration request settings** (Einstellungen für Integrationsanforderungen) die Option **Edit** (Bearbeiten) aus.

1. Wählen Sie für **Integration type** (Integrationstyp) eine der folgenden Optionen:
   + Wählen Sie die **Lambda-Funktion** nur, wenn Ihre API in eine AWS Lambda Funktion integriert wird, die Sie bereits in diesem Konto oder in einem anderen Konto erstellt haben.

     **Um eine neue Lambda-Funktion in zu erstellen AWS Lambda, eine Ressourcenberechtigung für die Lambda-Funktion festzulegen oder andere Lambda-Serviceaktionen auszuführen, wählen Sie AWS stattdessen Service.**
   + Wählen Sie **HTTP**, wenn Ihre API in einen vorhandenen HTTP-Endpunkt integriert wird. Weitere Informationen finden Sie unter [HTTP-Integrationen für REST APIs in API Gateway](setup-http-integrations.md).
   + Wählen Sie **Mock**, wenn Sie API-Antworten direkt von API Gateway generieren möchten, ohne dass ein Integrations-Backend erforderlich ist. Weitere Informationen finden Sie unter [Scheinintegrationen für REST APIs in API Gateway](how-to-mock-integration.md).
   + Wählen Sie **AWS Service**, wenn Ihre API in einen Dienst integriert werden soll. AWS 
   + Wählen Sie **VPC Link** (VPC-Link), wenn Ihre API einen `VpcLink` als privaten Integrations-Endpunkt verwenden wird. Weitere Informationen finden Sie unter [Richten Sie eine private Integration ein](set-up-private-integration.md).

1. Wenn Sie **Lambda Function** (Lambda-Funktion) wählen, gehen Sie wie folgt vor:

   1. Markieren Sie unter **Use Lambda Proxy integration** (Lambda-Proxy-Integration verwenden) das Kontrollkästchen, wenn Sie die [Lambda-Proxy-Integration](set-up-lambda-proxy-integrations.md#api-gateway-create-api-as-simple-proxy) oder die [kontoübergreifende Lambda-Proxy-Integration](apigateway-cross-account-lambda-integrations.md) verwenden möchten.

   1. Geben Sie für **Lambda Function** (Lambda-Funktion) die Funktion auf eine der folgenden Arten an:
      + Wenn sich Ihre Lambda-Funktion in demselben Konto befindet, geben Sie den Funktionsnamen ein und wählen Sie dann die Funktion aus der Dropdown-Liste aus.
**Anmerkung**  
Der Funktionsname kann optional seinen Alias oder seine Versionsangabe, wie in `HelloWorld`, `HelloWorld:1` oder `HelloWorld:alpha`, enthalten.
      + Wenn sich die Funktion in einem anderen Konto befindet, geben Sie den ARN für die Funktion ein.

   1. Wenn Sie den Timeout-Standardwert von 29 Sekunden verwenden möchten, lassen Sie das Kontrollkästchen **Default timeout** (Standardzeitüberschreitung) aktiviert. Wenn Sie einen benutzerdefinierten Zeitüberschreitungswert festlegen möchten, wählen Sie **Default timeout** (Standardzeitüberschreitung) aus und geben Sie einen Zeitüberschreitungswert zwischen `50` und `29000` Millisekunden ein.

1. Befolgen Sie bei Wahl von **HTTP** die Anweisungen in Schritt 4 von [API-Integrationsanfrage über die API Gateway-Konsole einrichten](how-to-method-settings-console.md).

1. Befolgen Sie bei Wahl von **Mock (Pseudo)** die Anweisungen unter dem Schritt **Request Templates (Vorlagen anfordern)**.

1. Befolgen Sie bei Wahl von **AWS -Service** die Anweisungen in Schritt 6 von [API-Integrationsanfrage über die API Gateway-Konsole einrichten](how-to-method-settings-console.md).

1. Wenn Sie **VPC Link** (VPC-Link) ausgewählt haben, gehen Sie wie folgt vor:

   1. Markieren Sie für **VPC proxy integration** (Proxy-Integration verwenden) das Kontrollkästchen, wenn Anforderungen über einen Proxy an Ihren `VPCLink`-Endpunkt gesendet werden sollen.

   1. Wählen Sie als **HTTP method** die HTTP-Methode aus, die am ehesten der Methode im HTTP-Backend entspricht.

   1. Wählen Sie in der Dropdownliste **VPC link** (VPC-Link) einen VPC-Link aus. Sie können `[Use Stage Variables]` auswählen und **\$1\$1stageVariables.vpcLinkId\$1** in das Textfeld unter der Liste eingeben.

      Sie können die `vpcLinkId`-Stufenvariable nach der Bereitstellung der API für eine Stufe definieren und ihren Wert auf die ID des `VpcLink` festlegen.

   1. Geben Sie als **Endpunkt-URL** die URL des HTTP-Backends ein, das von dieser Integration verwendet werden soll.

   1. Wenn Sie die Standardzeitüberschreitung von 29 Sekunden verwenden möchten, lassen Sie das Kontrollkästchen **Default timeout** (Standardzeitüberschreitung) aktiviert. Wenn Sie einen benutzerdefinierten Zeitüberschreitungswert festlegen möchten, wählen Sie **Default timeout** (Standardzeitüberschreitung) aus und geben Sie einen Zeitüberschreitungswert zwischen `50` und `29000` Millisekunden ein.

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

1. Führen Sie unter **Request Templates** (Vorlagen anfordern) die folgenden Schritte durch:

   1. Um einen **Template selection expression** (Vorlagen-Auswahlausdruck) einzugeben, wählen Sie unter **Request templates** (Vorlagen anfordern) die Option **Edit** (Bearbeiten).

   1. Geben Sie einen **Template selection expression** (Vorlagen-Auswahlausdruck) ein. Verwenden Sie einen Ausdruck, nach dem API Gateway in der Nachrichtennutzlast sucht. Wenn er gefunden wird, wird er ausgewertet. Das Ergebnis ist ein Vorlagen-Schlüsselwert zur Auswahl der Datenzuweisungsvorlage, die auf die Daten in der Nachrichtennutzlast anzuwenden ist. Die Datenzuweisungsvorlage erstellen Sie im nächsten Schritt. Wählen Sie **Edit** (Bearbeiten) aus, um Ihre Änderungen zu speichern.

   1. Wählen Sie **Create template** (Vorlage erstellen), um die Datenzuweisungsvorlage zu erstellen. Geben Sie für **Template key** (Vorlagenschlüssel) einen Vorlagenschlüsselwert zur Auswahl der Datenzuweisungsvorlage ein, die auf die Daten in der Nachrichtennutzlast anzuwenden ist. Definieren Sie anschließend eine Zuweisungsvorlage. Wählen Sie **Create template (Vorlage erstellen)** aus.

      Weitere Informationen zu Vorlagen-Auswahlausdrücken finden Sie unter [Vorlagen-Auswahlausdrücke](websocket-api-data-transformations.md#apigateway-websocket-api-template-selection-expressions).

## Richten Sie eine Integrationsanfrage ein, indem Sie AWS CLI
<a name="apigateway-websocket-api-integration-request-using-awscli"></a>

Sie können eine Integrationsanfrage für eine Route in einer WebSocket API einrichten, indem Sie AWS CLI wie im folgenden Beispiel vorgehen, wodurch eine Scheinintegration erstellt wird:

1. Erstellen Sie eine Datei mit dem Namen `integration-params.json` und dem folgenden Inhalt:

   ```
   {"PassthroughBehavior": "WHEN_NO_MATCH", "TimeoutInMillis": 29000, "ConnectionType": "INTERNET", "RequestTemplates": {"application/json": "{\"statusCode\":200}"}, "IntegrationType": "MOCK"}
   ```

1. Verwenden Sie den folgenden [create-integration](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-integration.html)-Befehl, um die Mock-Integration zu erstellen.

   ```
   aws apigatewayv2 --region us-east-1 create-integration --api-id aabbccddee --cli-input-json file://integration-params.json
   ```

   Die Ausgabe sieht wie folgt aus:

   ```
   {
       "PassthroughBehavior": "WHEN_NO_MATCH",
       "TimeoutInMillis": 29000,
       "ConnectionType": "INTERNET",
       "IntegrationResponseSelectionExpression": "${response.statuscode}",
       "RequestTemplates": {
           "application/json": "{\"statusCode\":200}"
       },
       "IntegrationId": "0abcdef",
       "IntegrationType": "MOCK"
   }
   ```

Alternativ können Sie eine Integrationsanfrage für eine Proxyintegration einrichten, indem Sie den verwenden AWS CLI.

1. Erstellen Sie eine Lambda-Funktion in der Lambda-Konsole und geben Sie ihr eine grundlegende Lambda-Ausführungsrolle.

1. Verwenden Sie den folgenden [create-integration](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-integration.html)–Befehl, um eine Integration zu erstellen.

   ```
   aws apigatewayv2 create-integration --api-id aabbccddee --integration-type AWS_PROXY --integration-method POST --integration-uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123412341234:function:simpleproxy-echo-e2e/invocations
   ```

Die Ausgabe sieht wie folgt aus:

```
{
    "PassthroughBehavior": "WHEN_NO_MATCH",
    "IntegrationMethod": "POST",
    "TimeoutInMillis": 29000,
    "ConnectionType": "INTERNET",
    "IntegrationUri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123412341234:function:simpleproxy-echo-e2e/invocations",
    "IntegrationId": "abcdefg",
    "IntegrationType": "AWS_PROXY"
}
```

## Eingabeformat einer Lambda-Funktion für die Proxyintegration für WebSocket APIs
<a name="api-gateway-simple-proxy-for-lambda-input-format-websocket"></a>

Bei der Lambda-Proxy-Integration ordnet API Gateway die gesamte Client-Anforderung dem `event`-Eingabeparameter der Backend-Lambda-Funktion zu. Im folgenden Beispiel sehen Sie die Struktur des Eingabeereignisses der `$connect`-Route und des Eingabeereignisses der `$disconnect`-Route, die das API Gateway an eine Lambda-Proxy-Integration sendet.

------
#### [ Input from the \$1connect route ]

```
{
    headers: {
      Host: 'abcd123.execute-api.us-east-1.amazonaws.com',
      'Sec-WebSocket-Extensions': 'permessage-deflate; client_max_window_bits',
      'Sec-WebSocket-Key': '...',
      'Sec-WebSocket-Version': '13',
      'X-Amzn-Trace-Id': '...',
      'X-Forwarded-For': '192.0.2.1',
      'X-Forwarded-Port': '443',
      'X-Forwarded-Proto': 'https'
    },
    multiValueHeaders: {
      Host: [ 'abcd123.execute-api.us-east-1.amazonaws.com' ],
      'Sec-WebSocket-Extensions': [ 'permessage-deflate; client_max_window_bits' ],
      'Sec-WebSocket-Key': [ '...' ],
      'Sec-WebSocket-Version': [ '13' ],
      'X-Amzn-Trace-Id': [ '...' ],
      'X-Forwarded-For': [ '192.0.2.1' ],
      'X-Forwarded-Port': [ '443' ],
      'X-Forwarded-Proto': [ 'https' ]
    },
    requestContext: {
      routeKey: '$connect',
      eventType: 'CONNECT',
      extendedRequestId: 'ABCD1234=',
      requestTime: '09/Feb/2024:18:11:43 +0000',
      messageDirection: 'IN',
      stage: 'prod',
      connectedAt: 1707502303419,
      requestTimeEpoch: 1707502303420,
      identity: { sourceIp: '192.0.2.1' },
      requestId: 'ABCD1234=',
      domainName: 'abcd1234.execute-api.us-east-1.amazonaws.com',
      connectionId: 'AAAA1234=',
      apiId: 'abcd1234'
    },
    isBase64Encoded: false
  }
```

------
#### [ Input from the \$1disconnect route ]

```
{
    headers: {
      Host: 'abcd1234.execute-api.us-east-1.amazonaws.com',
      'x-api-key': '',
      'X-Forwarded-For': '',
      'x-restapi': ''
    },
    multiValueHeaders: {
      Host: [ 'abcd1234.execute-api.us-east-1.amazonaws.com' ],
      'x-api-key': [ '' ],
      'X-Forwarded-For': [ '' ],
      'x-restapi': [ '' ]
    },
    requestContext: {
      routeKey: '$disconnect',
      disconnectStatusCode: 1005,
      eventType: 'DISCONNECT',
      extendedRequestId: 'ABCD1234=',
      requestTime: '09/Feb/2024:18:23:28 +0000',
      messageDirection: 'IN',
      disconnectReason: 'Client-side close frame status not set',
      stage: 'prod',
      connectedAt: 1707503007396,
      requestTimeEpoch: 1707503008941,
      identity: { sourceIp: '192.0.2.1' },
      requestId: 'ABCD1234=',
      domainName: 'abcd1234.execute-api.us-east-1.amazonaws.com',
      connectionId: 'AAAA1234=',
      apiId: 'abcd1234'
    },
    isBase64Encoded: false
  }
```

------

# Richten Sie eine WebSocket API-Integrationsantwort in API Gateway ein
<a name="apigateway-websocket-api-integration-responses"></a>

Der folgende Abschnitt bietet einen kurzen Überblick über Integrationsantworten für WebSocket API und wie eine Integrationsantwort für eine WebSocket API eingerichtet wird. 

**Topics**
+ [Übersicht über Integrationsantworten](#apigateway-websocket-api-integration-response-overview)
+ [Integrationsantworten für bidirektionale Kommunikation](#apigateway-websocket-api-integration-response-for-two-way-communication)
+ [Integrationsantwort mit der API Gateway-Konsole einrichten](#apigateway-websocket-api-integration-response-using-console)
+ [Richten Sie eine Integrationsantwort mit dem ein AWS CLI](#apigateway-websocket-api-integration-response-using-awscli)

## Übersicht über Integrationsantworten
<a name="apigateway-websocket-api-integration-response-overview"></a>

Die Integrationsantwort von API Gateway ist eine Möglichkeit, die Antwort von einem Backend-Service zu modellieren und zu manipulieren. Es gibt einige Unterschiede bei der Einrichtung einer REST-API und einer WebSocket API-Integrationsantwort, aber konzeptionell ist das Verhalten dasselbe.

WebSocket Routen können für bidirektionale oder unidirektionale Kommunikation konfiguriert werden.
+ Wenn eine Route für bidirektionale Kommunikation konfiguriert ist, können Sie mit einer Integrationsantwort Transformationen für die zurückgegebene Nachrichtennutzlast konfigurieren, ähnlich wie bei Integrationsantworten für REST. APIs
+ Wenn eine Route für unidirektionale Kommunikation konfiguriert ist, wird unabhängig von der Konfiguration der Integrationsantwort nach der Verarbeitung der Nachricht keine Antwort über den WebSocket Kanal zurückgegeben.

 API Gateway übergibt die Backend-Antwort nicht über die Routenantwort, es sei denn, Sie richten eine Routenantwort ein. Weitere Informationen zum Einrichten einer Routenreaktion finden Sie unter [Richten Sie Routenantworten für WebSocket APIs in API Gateway ein](apigateway-websocket-api-route-response.md).

## Integrationsantworten für bidirektionale Kommunikation
<a name="apigateway-websocket-api-integration-response-for-two-way-communication"></a>

Integrationen lassen sich in *Proxy*-Integrationen und *Nicht-Proxy*-Integrationen unterteilen.

**Wichtig**  
Bei *Proxy-Integrationen* gibt API Gateway automatisch die Backend-Ausgabe als vollständigen Payload an den Aufrufer weiter. Es gibt keine Integrationsantwort.

Bei *Nicht-Proxy-Integrationen* müssen Sie mindestens eine Integrationsantwort einrichten:
+ Im Idealfall sollte eine Ihrer Integrationsantworten als Catch-all-Methode dienen, wenn keine explizite Wahl vorgenommen werden kann. Dieser Standardfall wird durch Festlegen des Integrationsantwort-Schlüssels dargestell `$default`.
+ In allen anderen Fällen fungiert der Integrationsantwort-Schlüssel als regulärer Ausdruck. Er sollte dem Format folge `"/expression/"`.

Bei Nicht-Proxy-HTTP-Integrationen:
+ API Gateway versucht, den HTTP-Statuscode der Backend-Antwort zuzuordnen. Der Integrationsantwort-Schlüssel fungiert in diesem Fall als regulärer Ausdruck. Wenn keine Übereinstimmung gefunden wird, dann wird `$default` als Integrationsantwort gewählt.
+ Der Vorlagen-Auswahlausdruck funktioniert wie oben beschrieben identisch. Zum Beispiel:
  + `/2\d\d/`: Erfolgreiche Antworten empfangen und transformieren
  + `/4\d\d/`: Fehler (ungültige Anforderung) empfangen und transformieren
  + `$default`: Alle unerwarteten Antworten empfangen und transformieren

Weitere Informationen zu Vorlagen-Auswahlausdrücken finden Sie unter [Vorlagen-Auswahlausdrücke](websocket-api-data-transformations.md#apigateway-websocket-api-template-selection-expressions).

## Integrationsantwort mit der API Gateway-Konsole einrichten
<a name="apigateway-websocket-api-integration-response-using-console"></a>

So richten Sie mithilfe der API-Gateway-Konsole eine Antwort zur Routenintegration für eine WebSocket API ein:

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 Ihre WebSocket API und wählen Sie Ihre Route.

1. Wählen Sie die Registerkarte **Integration request** (Integrationsanforderung) und dann im Abschnitt **Integration request settings** (Einstellungen für Integrationsanforderungen) die Option **Create integration response** (Integrationsantwort erstellen) aus.

1. Geben Sie für **Antwortschlüssel** einen Wert ein, der nach Auswertung des Ausdrucks der Antwortauswahl im Antwortschlüssel der ausgehenden Nachricht zu finden ist. Sie können beispielsweise **/4\$1d\$1d/** eingeben, um Anforderungsfehler zu empfangen und umzuwandeln, oder Sie können **\$1default** eingeben, um alle Antworten zu empfangen und umzuwandeln, die dem Ausdruck für die Vorlagenauswahl entsprechen. 

1. Geben Sie unter **Template selection expression** (Ausdruck für die Vorlagenauswahl) einen Auswahlausdruck ein, um die ausgehende Nachricht auszuwerten.

1. Wählen Sie **Create response** (Antwort erstellen) aus.

1. Sie können auch eine Zuordnungsvorlage definieren, um Transformationen Ihrer Payload für zurückgegebene Nachrichten zu konfigurieren. Wählen Sie **Create template (Vorlage erstellen)** aus.

1. Geben Sie einen Schlüsselnamen ein. Wenn Sie den Standardausdruck für die Vorlagenauswahl auswählen, geben Sie **\$1\$1default** ein.

1. Geben Sie unter **Response template** (Antwortvorlage) Ihre Zuordnungsvorlage in den Code-Editor ein.

1. Wählen Sie **Create template (Vorlage erstellen)** aus.

1. Wählen Sie **Deploy API** (API bereitstellen) aus, um Ihre API bereitzustellen.

 Stellen Sie mit dem folgenden [wscat](https://www.npmjs.com/package/wscat)-Befehl eine Verbindung mit Ihrer API her. Mehr über `wscat` erfahren Sie unter [Wird verwendet`wscat`, um eine Verbindung zu einer WebSocket API herzustellen und Nachrichten an diese zu senden](apigateway-how-to-call-websocket-api-wscat.md). 

```
wscat -c wss://api-id.execute-api.us-east-2.amazonaws.com/test
```

 Wenn Sie Ihre Route aufrufen, sollte die Payload der zurückgegebenen Nachricht zurückgegeben werden. 

## Richten Sie eine Integrationsantwort mit dem ein AWS CLI
<a name="apigateway-websocket-api-integration-response-using-awscli"></a>

Der folgende [create-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-integration-response.html)Befehl erstellt eine `$default` Integrationsantwort:

```
aws apigatewayv2 create-integration-response \
    --api-id vaz7da96z6 \
    --integration-id a1b2c3 \
    --integration-response-key '$default'
```

# Validierung für WebSocket APIs im API Gateway anfordern
<a name="websocket-api-request-validation"></a>

Sie können API Gateway so konfigurieren, dass die Validierung einer Routenanforderung durchgeführt wird, bevor Sie mit der Integrationsanforderung fortfahren. Wenn die Validierung fehlschlägt, schlägt API Gateway die Anfrage fehl, ohne Ihr Backend aufzurufen, sendet eine Gateway-Antwort „Bad Request Body“ an den Client und veröffentlicht die Validierungsergebnisse in CloudWatch Logs. Die Verwendung der Validierung auf diese Weise reduziert unnötige Aufrufe an Ihr API-Backend.

## Modell-Auswahlausdrücke
<a name="apigateway-websocket-api-model-selection-expressions"></a>

Sie können einen Modell-Auswahlausdruck verwenden, um Anforderungen innerhalb derselben Route dynamisch zu validieren. Die Modellvalidierung erfolgt, wenn Sie einen Modell-Auswahlausdruck für Proxy- oder Nicht-Proxy-Integrationen bereitstellen. Möglicherweise müssen Sie das `$default`-Modell als Fallback definieren, wenn kein passendes Modell gefunden wird. Wenn kein übereinstimmendes Modell vorhanden ist und `$default` nicht definiert ist, schlägt die Validierung fehl. Der Auswahlausdruck ähnelt `Route.ModelSelectionExpression` und wertet den Schlüssel für `Route.RequestModels` aus.

Wenn Sie eine Route für eine WebSocket API definieren, können Sie optional einen *Modellauswahlausdruck* angeben. Dieser Ausdruck wird zur Auswahl des Modells ausgewertet, das bei Eingang einer Anforderung für die Textvalidierung verwendet werden soll. Der Ausdruck wird auf einen der Einträge in den einer Route ausgewertet [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes.html#apis-apiid-routes-prop-route-requestmodels](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes.html#apis-apiid-routes-prop-route-requestmodels).

Ein Modell wird als [JSON-Schema](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04) ausgedrückt und beschreibt die Datenstruktur des Anforderungstextes. Die Beschaffenheit dieses Auswahlausdrucks ermöglicht Ihnen, dynamisch das Modell auszuwählen, über das zur Laufzeit für eine bestimmte Route validiert werden soll. Weitere Informationen, wie Sie ein Modell erstellen können, finden Sie unter [Datenmodelle für REST APIs](models-mappings-models.md). 

## Einrichten der grundlegenden Anforderungsvalidierung über die API-Gateway-Konsole
<a name="apigateway-websocket-api-model-selection-expression-example"></a>

Im folgenden Beispiel wird gezeigt, wie Sie die Anforderungsvalidierung auf einer Route einrichten.

 Zuerst erstellen Sie ein Modell und dann eine Route. Als Nächstes konfigurieren Sie die Anforderungsvalidierung für die Route, die Sie gerade erstellt haben. Abschließend stellen Sie Ihre API bereit und testen sie. Um dieses Tutorial abzuschließen, benötigen Sie eine WebSocket API `$request.body.action` als Routenauswahlausdruck und einen Integrationsendpunkt für Ihre neue Route.

Sie benötigen außerdem `wscat`, um eine Verbindung zu Ihrer API herzustellen. Weitere Informationen finden Sie unter [Wird verwendet`wscat`, um eine Verbindung zu einer WebSocket API herzustellen und Nachrichten an diese zu senden](apigateway-how-to-call-websocket-api-wscat.md).

**So erstellen Sie ein Modell**

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

1. Klicken Sie im Navigationsbereich auf **Models** (Modelle).

1. Wählen Sie **Modell erstellen** aus.

1. Geben Sie unter **Name** **emailModel** ein.

1. Geben Sie für **Content type** (Inhaltstyp) **application/json** ein.

1. Geben Sie für **Modellschema** Folgendes ein:

   ```
   {
       "$schema": "http://json-schema.org/draft-04/schema#",
       "type" : "object",
       "required" : [ "address"],
       "properties" : {
           "address": {
               "type": "string"
           }
       }
   }
   ```

   Für dieses Modell muss die Anfrage eine E-Mail-Adresse enthalten.

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

In diesem Schritt erstellen Sie eine Route für Ihre WebSocket API.

**So erstellen Sie eine Route**

1. Klicken Sie im Hauptnavigationsbereich auf **Routen**.

1. Wählen Sie **Create route (Route erstellen)** aus.

1. Geben Sie in **Route key** (Routenschlüssel) **sendMessage** ein.

1. Wählen Sie einen Integrationstyp und geben Sie einen Integrationsendpunkt an. Weitere Informationen finden Sie unter [Integrationen für das WebSocket APIs API Gateway](apigateway-websocket-api-integrations.md).

1. Wählen Sie **Create route (Route erstellen)** aus.

In diesem Schritt richten Sie die Anforderungsvalidierung für die `sendMessage`-Route ein.

**Einrichten der Anforderungsvalidierung**

1. Klicken Sie auf der Registerkarte **Routenanforderung** unter **Routenanforderungseinstellungen** auf **Bearbeiten**.

1. Geben Sie unter **Modellauswahlausdruck** **\$1\$1request.body.messageType\$1** ein.

   API Gateway verwendet die `messageType`-Eigenschaft zur Validierung der eingehenden Anforderung.

1. Klicken Sie auf **Anforderungsmodell hinzufügen**.

1. Geben Sie für **Modellschlüssel** **email** ein.

1. Wählen Sie unter **Modell** die Option **emailModel** aus.

   API Gateway validiert eingehende Nachrichten mithilfe der `messageType`-Eigenschaft, die anhand dieses Modells auf `email` gesetzt ist.
**Anmerkung**  
Wenn API Gateway den Modellauswahlausdruck nicht mit einem Modellschlüssel abgleichen kann, wird das `$default`-Modell ausgewählt. Wenn kein `$default`-Modell vorhanden ist, schlägt die Validierung fehl. Für die Produktion empfehlen wir APIs, dass Sie ein `$default` Modell erstellen.

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

In diesem Schritt stellen Sie Ihre API bereit und testen sie.

**Bereitstellen und testen Ihrer API**

1. Klicken Sie auf **Deploy API**.

1. Wählen Sie die gewünschte Stufe aus der Dropdown-Liste aus oder geben Sie den Namen einer neuen Stufe ein.

1. Wählen Sie **Bereitstellen**.

1. Klicken Sie im Hauptnavigationsbereich auf **Stufen**.

1. Kopieren Sie die WebSocket URL Ihrer API. Die URL sollte wie `wss://abcdef123.execute-api.us-east-2.amazonaws.com/production` aussehen.

1. Öffnen Sie ein neues Terminal. Führen Sie den Befehl **wscat** mit den folgenden Parametern aus.

   ```
   wscat -c wss://abcdef123.execute-api.us-west-2.amazonaws.com/production
   ```

   ```
   Connected (press CTRL+C to quit)
   ```

1. Testen Sie Ihre API mit dem folgenden Befehl.

   ```
   {"action": "sendMessage", "messageType": "email"}
   ```

   ```
   {"message": "Invalid request body", "connectionId":"ABCD1=234", "requestId":"EFGH="}
   ```

   Die Anforderung schlägt in API Gateway fehl.

   Verwenden Sie den folgenden Befehl, um eine gültige Anforderung an Ihre API zu senden.

   ```
   {"action": "sendMessage", "messageType": "email", "address": "mary_major@example.com"}
   ```

# Datentransformationen für WebSocket APIs im API Gateway
<a name="websocket-api-data-transformations"></a>

In API Gateway kann die Methodenanforderung einer WebSocket API eine Nutzlast in einem anderen Format als die entsprechende Nutzlast der Integrationsanfrage annehmen, wie es im Backend erforderlich ist. Das Backend wiederum kann eine Integrationsantwortnutzlast zurückgeben, die nicht der Methodenantwortnutzlast entspricht, die das Frontend erwartet. 

In Amazon API Gateway können Sie Zuweisungsvorlagen verwenden, um die Nutzdaten einer Methodenanforderung der entsprechenden Integrationsanforderung zuzuordnen bzw. die Nutzdaten einer Integrationsanforderung der entsprechenden Methodenantwort zuzuordnen. Sie erstellen eine Zuweisungsvorlage und geben einen Vorlagen-Auswahlausdruck an, um zu bestimmen, welche Vorlage für die erforderlichen Datentransformationen verwendet werden soll.

Sie können Datenzuordnungen verwenden, um Daten aus einer [Routenanforderung](api-gateway-basic-concept.md#apigateway-definition-route-request) einer Backend-Integration zuzuordnen. Weitere Informationen hierzu finden Sie unter [Datenzuordnung für WebSocket APIs in API Gateway einrichten](websocket-api-data-mapping.md).

## Zuweisungsvorlagen und Modelle
<a name="apigateway-websocket-api-mapping-templats-and-models"></a>

 [Eine *Mapping-Vorlage* ist ein in [Velocity Template Language (VTL)](https://velocity.apache.org/engine/devel/vtl-reference.html) ausgedrücktes Skript, das mithilfe von Ausdrücken auf die Nutzlast angewendet wird. JSONPath ](https://goessner.net/articles/JsonPath/) Weitere Informationen über API Gateway-Zuordnungsvorlagen finden Sie unter [Zuordnen von Vorlagentransformationen für REST APIs in API Gateway](models-mappings.md).

Die Nutzlast kann ein dem [JSON-Schema Entwurf 4](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04) entsprechendes *Datenmodell* umfassen. Sie müssen kein Modell definieren, um eine Zuweisungsvorlage zu erstellen. Ein Modell kann Ihnen jedoch bei der Erstellung einer Vorlage helfen, da API Gateway einen Vorlagenentwurf auf der Grundlage eines bereitgestellten Modells generiert. Weitere Informationen über API Gateway-Modelle finden Sie unter [Datenmodelle für REST APIs](models-mappings-models.md).

## Vorlagen-Auswahlausdrücke
<a name="apigateway-websocket-api-template-selection-expressions"></a>

[Um eine Payload mit einer Mapping-Vorlage zu transformieren, geben Sie in einer [Integrationsanfrage oder Integrationsantwort](apigateway-websocket-api-integration-requests.md) einen Ausdruck für die WebSocket API-Vorlagenauswahl an.](apigateway-websocket-api-integration-responses.md) Durch Auswerten dieses Ausdrucks wird die Eingabe- oder Ausgabevorlage (falls vorhanden) bestimmt, die zum Transformieren des Anforderungstexts in den Integrationsanforderungstext (über eine Eingabevorlage) oder des Integrationsantworttext in den Routenantworttext (über eine Ausgabevorlage) verwendet werden soll.

`Integration.TemplateSelectionExpression` unterstützt `${request.body.jsonPath}` und statische Werte.

`IntegrationResponse.TemplateSelectionExpression` unterstützt `${request.body.jsonPath}`, `${integration.response.statuscode}`, `${integration.response.header.headerName}`, `${integration.response.multivalueheader.headerName}` und statische Werte.

## Integrationsantwort-Auswahlausdrücke
<a name="apigateway-websocket-api-integration-response-selection-expressions"></a>

Wenn Sie [eine Integrationsantwort für eine WebSocket API einrichten](apigateway-websocket-api-integration-responses.md), können Sie optional einen Auswahlausdruck für eine Integrationsantwort angeben. Dieser Ausdruck bestimmt, welche `[https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid-integrationresponses-integrationresponseid.html](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid-integrationresponses-integrationresponseid.html)` ausgewählt werden sollte, wenn eine Integration zurückgegeben wird. Der Wert dieses Ausdrucks wird zurzeit durch API Gateway eingeschränkt, wie nachfolgend definiert. Beachten Sie, dass dieser Ausdruck nur für *Nicht-Proxy-Integrationen* relevant ist. Eine Proxy-Integration übergibt die Antwortnutzlast einfach ohne Modellierung oder Modifikation an die aufrufende Methode zurück.

Im Gegensatz zu den anderen vorhergehenden Auswahlausdrücken unterstützt dieser Ausdruck derzeit ein *Musterabgleich*-Format. Der Ausdruck sollte in Schrägstriche verpackt werden.

Derzeit ist der Wert je nach fixier `[https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid.html#apis-apiid-integrations-integrationid-prop-integration-integrationtype](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid.html#apis-apiid-integrations-integrationid-prop-integration-integrationtype)`:
+ Für Lambda-basierte Integrationen lautet er `$integration.response.body.errorMessage`.
+ Für `HTTP`- und `MOCK`-Integrationen ist dies `$integration.response.statuscode`.
+ Für `HTTP_PROXY` und `AWS_PROXY` wird der Ausdruck nicht verwendet, da Sie anfordern, dass die Nutzlast über die aufrufende Methode übergeben wird.

# Datenzuordnung für WebSocket APIs in API Gateway einrichten
<a name="websocket-api-data-mapping"></a>

Mit der *Datenzuordnung* können Sie Daten aus einer [Routenanforderung](api-gateway-basic-concept.md#apigateway-definition-route-request) einer Backend-Integration zuordnen.

**Anmerkung**  
Die Datenzuordnung für wird in der WebSocket APIs nicht unterstützt AWS-Managementkonsole. Sie müssen das AWS CLI, oder ein SDK verwenden AWS CloudFormation, um die Datenzuordnung zu konfigurieren.

**Topics**
+ [Zuordnen von Routenanforderungsdaten zu Integrationsanforderungsparametern](#websocket-mapping-request-parameters)
+ [Beispiele](#websocket-data-mapping-examples)

## Zuordnen von Routenanforderungsdaten zu Integrationsanforderungsparametern
<a name="websocket-mapping-request-parameters"></a>

Integrationsanforderungsparameter können aus beliebigen definierten Routenanforderungsparametern, dem Anforderungstext [`context` oder ](api-gateway-mapping-template-reference.md#context-variable-reference) [`stage`](api-gateway-mapping-template-reference.md#stagevariables-template-reference)-Variablen und statischen Werten zugeordnet werden.

In der folgenden Tabelle sehen Sie Datenzuordnungsausdrücke für Integrationsanfragen. In der Tabelle ist *`PARAM_NAME`* der Name eines Routenanforderungsparameters des angegebenen Parametertyps. Es muss mit dem regulären Ausdruck übereinstimmen`'^[a-zA-Z0-9._$-]+$]'`. *JSONPath\$1EXPRESSION*ist ein JSONPath Ausdruck für ein JSON-Feld des Hauptteils der Anfrage.


| Zugewiesene Datenquelle | Mapping-Ausdruck | 
| --- | --- | 
| Anforderungsabfragezeichenfolge (wird nur für die \$1connect-Route unterstützt) | route.request.querystring.PARAM\$1NAME | 
| Anforderungs-Header (wird nur für die \$1connect-Route unterstützt) | route.request.header.PARAM\$1NAME | 
| Abfragezeichenfolge mit mehreren Werten (nur für die \$1connect-Route unterstützt) | route.request.multivaluequerystring.PARAM\$1NAME | 
| Anforderungsheader mit mehreren Werten (nur für die \$1connect-Route unterstützt) | route.request.multivalueheader.PARAM\$1NAME | 
| Anforderungstext | route.request.body.JSONPath\$1EXPRESSION | 
| Stufenvariablen | stageVariables.VARIABLE\$1NAME | 
| Kontextvariablen | context.VARIABLE\$1NAME, wobei die Variable zu den [unterstützten Kontextvariablen](api-gateway-mapping-template-reference.md#context-variable-reference) gehören muss. | 
| Statischer Wert | 'STATIC\$1VALUE'. Das STATIC\$1VALUE ist ein Zeichenkettenliteral und muss in einfache Anführungszeichen eingeschlossen werden. | 

Achten Sie beim Erstellen einer Datenzuordnung auf das AWS CLI richtige Format für die Verwendung von Literalen mit Zeichenfolgen in. AWS CLI Weitere Informationen finden Sie unter [Verwenden von Zeichenfolgen mit Anführungszeichen in der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) im *Benutzerhandbuch zur AWS Command Line Interface *.

## Beispiele
<a name="websocket-data-mapping-examples"></a>

In den folgenden AWS CLI Beispielen werden Datenzuordnungen konfiguriert. Eine CloudFormation Beispielvorlage finden Sie unter. [samples/websocket-data-mapping.zip](samples/websocket-data-mapping.zip)

### Zuordnen der ConnectionID eines Clients zu einem Header in einer Integrationsanforderung
<a name="websocket-data-mapping-examples.connectionId"></a>

Der folgende [update-integration](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-integration.html)-Befehl weist die `connectionId` eines Clients dem `connectionId`-Header in der Anfrage an eine Backend-Integration zu:

```
aws apigatewayv2 update-integration \
    --integration-id abc123 \
    --api-id a1b2c3d4 \ 
    --request-parameters 'integration.request.header.connectionId'='context.connectionId'
```

### Zuordnen eines Abfragezeichenfolgenparameters zu einem Header in einer Integrationsanforderung
<a name="websocket-data-mapping-examples.querystring"></a>

Das folgende Beispiel weist einen `authToken`-Abfragezeichenfolgenparameter dem `authToken`-Header in der Integrationsanforderung zu.

1. Verwenden Sie den folgenden [update-route](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-route.html)-Befehl, um den `authToken`-Abfragezeichenfolgenparameter zu den Anforderungsparametern der Route hinzuzufügen.

   ```
   aws apigatewayv2 update-route --route-id 0abcdef \
       --api-id a1b2c3d4 \
       --request-parameters '{"route.request.querystring.authToken": {"Required": false}}'
   ```

1.  Verwenden Sie den folgenden [update-integration](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-integration.html)-Befehl, um den Abfragezeichenfolgenparameter dem `authToken`-Header in der Anfrage an die Backend-Integration zuzuweisen.

   ```
   aws apigatewayv2 update-integration \
       --integration-id abc123 \
       --api-id a1b2c3d4 \
       --request-parameters 'integration.request.header.authToken'='route.request.querystring.authToken'
   ```

1. (Optional) Gehen Sie bei Bedarf wie folgt vor, [delete-route-request-parameter](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/delete-route-request-parameter.html)um den `authToken` Abfragezeichenfolgenparameter aus den Anforderungsparametern der Route zu löschen.

   ```
   aws apigatewayv2 delete-route-request-parameter \
       --route-id 0abcdef \
       --api-id a1b2c3d4 \
       --request-parameter-key 'route.request.querystring.authToken'
   ```

# WebSocket Referenz zur API-Zuordnungsvorlage für API Gateway
<a name="apigateway-websocket-api-mapping-template-reference"></a>

In diesem Abschnitt werden die Variablen zusammengefasst, die derzeit WebSocket APIs in API Gateway unterstützt werden.


| Parameter | Beschreibung | 
| --- | --- | 
| \$1context.connectionId |  Eine eindeutige ID für die Verbindung, die für einen Rückruf an den Client verwendet werden kann.  | 
| \$1context.connectedAt |  Die [Epoch](https://en.wikipedia.org/wiki/Unix_time)-formatierte Verbindungszeit.  | 
| \$1context.domainName |  Ein Domainname für die WebSocket API. Dies kann für einen Rückruf an den Client (anstelle eines hardcodierten Wertes) verwendet werden.  | 
| \$1context.eventType |  Der Ereignistyp: `CONNECT`, `MESSAGE` oder `DISCONNECT`.  | 
| \$1context.messageId |  Eine eindeutige serverseitige ID für eine Nachricht. Nur verfügbar, wenn der `$context.eventType` `MESSAGE` ist.  | 
| \$1context.routeKey |  Der ausgewählte Routenschlüssel.  | 
| \$1context.requestId |  Entspricht `$context.extendedRequestId`.  | 
| \$1context.extendedRequestId | Eine automatisch generierte ID für den API-Aufruf, die weitere nützliche Informationen für das Debugging/die Fehlerbehebung enthält. | 
| \$1context.apiId |  Die ID, die API Gateway Ihrer API zuweist.  | 
| \$1context.authorizer.principalId |  Die ID des Prinzipalbenutzer, die dem vom Client gesendeten und von einer Lambda-Funktion eines API Gateway-Lambda-Genehmigers (früher "benutzerdefinierter Genehmiger") zurückgegebenen Token zugeordnet ist.  | 
| \$1context.authorizer.property |  Der in einer Zeichenfolge umgewandelte Wert des angegebenen Schlüssel-Wert-Paares der `context`-Zuordnung, der von einer API Gateway Lambda-Genehmigerfunktion zurückgegeben wird. Angenommen, der Genehmiger gibt folgende `context`-Zuweisung zurück:  <pre>"context" : {<br />  "key": "value",<br />  "numKey": 1,<br />  "boolKey": true<br />}</pre> Dann gibt der Aufruf von `$context.authorizer.key` die Zeichenfolge `"value"` zurück, der Aufruf von `$context.authorizer.numKey` gibt die Zeichenfolge `"1"` zurück und der Aufruf von `$context.authorizer.boolKey` gibt den Wert `"true"` zurück.  | 
| \$1context.error.messageString | Die Wert von \$1context.error.message in Anführungszeichen, d. h. "\$1context.error.message". | 
| \$1context.error.validationErrorString |  Eine Zeichenfolge mit einer detaillierten Validierungs-Fehlermeldung.  | 
| \$1context.identity.accountId |  Die der Anfrage zugeordnete AWS Konto-ID.  | 
| \$1context.identity.apiKey |  Der API-Besitzerschlüssel, der der schlüsselfähigen API-Anforderung zugewiesen ist.  | 
| \$1context.identity.apiKeyId | Die API-Schlüssel-ID, die der schlüsselfähigen API-Anforderung zugewiesen ist | 
| \$1context.identity.caller |  Die Prinzipal-ID des Aufrufers, von dem die Anforderung stammt.  | 
| \$1context.identity.cognitoAuthenticationProvider |  Eine durch Komma getrennte Liste aller Amazon-Cognito-Authentifizierungsanbieter, die vom anfordernden Aufrufer verwendet werden. Nur verfügbar, wenn die Anfrage mit Anmeldeinformationen von Amazon Cognito signiert wurde.  Zum Beispiel für eine Identität aus einem Amazon Cognito-Benutzerpool, `cognito-idp. region.amazonaws.com/user_pool_id,cognito-idp.region.amazonaws.com/user_pool_id:CognitoSignIn:token subject claim` Weitere Informationen zu verfügbaren Amazon-Cognito-Authentifizierungsanbietern finden Sie unter [Verbundidentitäten verwenden](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html) im *Amazon-Cognito-Entwicklerhandbuch*. | 
| \$1context.identity.cognitoAuthenticationType |  Der Amazon Cognito-Authentifizierungstyp des Aufrufers, der den Anfrage erstellt hat. Nur verfügbar, wenn die Anfrage mit Anmeldeinformationen von Amazon Cognito signiert wurde. Mögliche Werte sind `authenticated` für authentifizierte Identitäten und `unauthenticated` für nicht authentifizierte Identitäten. | 
| \$1context.identity.cognitoIdentityId |  Die Amazon Cognito Identitäts-ID des anfordernden Aufrufers. Nur verfügbar, wenn die Anfrage mit Anmeldeinformationen von Amazon Cognito signiert wurde.  | 
| \$1context.identity.cognitoIdentityPoolId |  Die Amazon Cognito Identitätspool-ID des anfordernden Aufrufers. Nur verfügbar, wenn die Anfrage mit Anmeldeinformationen von Amazon Cognito signiert wurde.  | 
| \$1context.identity.sourceIp |  Die Quell-IP-Adresse der TCP-Verbindung, von der die Anforderung an API Gateway gesendet wird.  | 
| \$1context.identity.user |  Die Prinzipal-ID des Benutzers, von dem die Anforderung stammt.  | 
| \$1context.identity.userAgent |  Der Benutzeragent des API-Aufrufers.  | 
| \$1context.identity.userArn |  Der ARN (Amazon Resource Name) des tatsächlichen Benutzers nach der Authentifizierung.  | 
| \$1context.requestTime | Die Anforderungszeit im [CLF](https://httpd.apache.org/docs/current/logs.html#common)-Format (dd/MMM/yyyy:HH:mm:ss \$1-hhmm). | 
| \$1context.requestTimeEpoch | Die Anforderungszeit im [Epoch](https://en.wikipedia.org/wiki/Unix_time)-Format in Millisekunden. | 
| \$1context.stage |  Die Bereitstellungsstufe des API-Aufrufs (z. B. "Beta" oder "Prod").  | 
| \$1context.status |  Der Antwortstatus.  | 
| \$1input.body | Gibt die Raw-Nutzlast als Zeichenfolge zurück. | 
| \$1input.json(x) | Diese Funktion wertet einen JSONPath Ausdruck aus und gibt die Ergebnisse als JSON-Zeichenfolge zurück. Beispielsweise gibt `$input.json('$.pets')` eine JSON-Zeichenfolge zurück, die die "Pets"-Struktur abbildet. Weitere Informationen zu JSONPath, finden Sie unter [JSONPath](https://goessner.net/articles/JsonPath/)oder [JSONPath für Java](https://github.com/json-path/JsonPath). | 
| \$1input.path(x) | Nimmt einen JSONPath Ausdruck string (`x`) und gibt eine JSON-Objektdarstellung des Ergebnisses zurück. Dies ermöglicht einen nativen Zugriff auf Elemente der Nutzlast in [Apache Velocity Template Language (VTL)](https://velocity.apache.org/engine/devel/vtl-reference.html) und deren Bearbeitung. Beispiel: Der Ausdruck `$input.path('$.pets')` könnte das folgende Objekt zurückgeben: <pre>[<br />  { <br />    "id": 1, <br />    "type": "dog", <br />    "price": 249.99 <br />  }, <br />  { <br />    "id": 2, <br />    "type": "cat", <br />    "price": 124.99 <br />  }, <br />  { <br />    "id": 3, <br />    "type": "fish", <br />    "price": 0.99 <br />  } <br />]</pre> `$input.path('$.pets').count()` gibt `"3"` zurück. Weitere Informationen zu JSONPath Java finden Sie unter [JSONPath](http://goessner.net/articles/JsonPath/)oder [JSONPath für Java](https://github.com/jayway/JsonPath). | 
| \$1stageVariables.<variable\$1name> |  *<variable\$1name>*steht für einen Stufenvariablennamen.  | 
| \$1stageVariables['<variable\$1name>'] |  *<variable\$1name>*steht für einen beliebigen Stufenvariablennamen.  | 
| \$1\$1stageVariables['<variable\$1name>']\$1 |  *<variable\$1name>*steht für einen beliebigen Stufenvariablennamen.  | 
| \$1util.escapeJavaScript() |  Escapiert die Zeichen in einer Zeichenfolge mithilfe von JavaScript Zeichenfolgenregeln.  Mit dieser Funktion werden alle einfachen Anführungszeichen (`'`) durch Escape-Zeichen (`\'`) geschützt. Allerdings sind diese durch Escape-Zeichen geschützten einfachen Anführungszeichen in JSON nicht zulässig. Sofern die Ausgabe dieser Funktion in einer JSON-Eigenschaft verwendet werden soll, müssen alle einfachen Anführungszeichen, die durch Escape-Zeichen geschützt sind (`\'`), wieder in reguläre einfache Anführungszeichen (`'`) geändert werden. Das wird im folgenden Beispiel veranschaulicht:  <pre> $util.escapeJavaScript(data).replaceAll("\\'","'")</pre>   | 
| \$1util.parseJson() |   Erhält das "stringify"-JSON-Objekt und gibt eine Objektdarstellung des Ergebnisses zurück. Mit dem Ergebnis dieser Funktion können Sie Elemente der Nutzlast, die in Apache Velocity Template Language (VTL) sind, aufrufen und bearbeiten. Angenommen, Sie haben folgende Nutzlast:  <pre>{"errorMessage":"{\"key1\":\"var1\",\"key2\":{\"arr\":[1,2,3]}}"}</pre>  Und verwenden die folgende Mapping-Vorlage:  <pre>#set ($errorMessageObj = $util.parseJson($input.path('$.errorMessage')))<br />{<br />   "errorMessageObjKey2ArrVal" : $errorMessageObj.key2.arr[0]<br />}<br /></pre> Dann erhalten Sie die folgende Ausgabe: <pre>{<br />   "errorMessageObjKey2ArrVal" : 1<br />}<br /></pre>  | 
| \$1util.urlEncode() | Konvertiert eine Zeichenfolge in das Format „application/x-www-form-urlencoded“. | 
| \$1util.urlDecode() | Dekodiert eine Zeichenfolge „application/x-www-form-urlencoded“. | 
| \$1util.base64Encode() | Codiert die Daten in eine base64-verschlüsselte Zeichenfolge. | 
| \$1util.base64Decode() | Decodiert die Daten einer base64-verschlüsselten Zeichenfolge. | 

# Binäre Medientypen für WebSocket-APIs in API Gateway
<a name="websocket-api-develop-binary-media-types"></a>

API Gateway-WebSocket-APIs unterstützen derzeit keine binären Frames in Payloads von eingehenden Nachrichten. Wenn eine Client-Anwendung einen Binär-Frame sendet, weist API Gateway diesen zurück und trennt die Verbindung zum Client mit dem Code 1003.

Es gibt eine Problemumgehung für dieses Verhalten. Wenn der Client textcodierte binäre Daten (z. B. base64) als Text-Frame sendet, können Sie für die `contentHandlingStrategy`-Eigenschaft der Integration `CONVERT_TO_BINARY` festlegen, um die Nutzlast von einer base64-codierten Zeichenfolge in eine binäre Zeichenfolge zu konvertieren. 

Damit für eine binäre Nutzlast in Nicht-Proxy-Integrationen eine Routenantwort zurückgegeben wird, können Sie für die `contentHandlingStrategy`-Eigenschaft der Integrationsantwort `CONVERT_TO_TEXT` festlegen, um die Nutzlast von einer binären in eine base64-codierte Zeichenfolge zu konvertieren.

# Aufrufen WebSocket APIs
<a name="apigateway-how-to-call-websocket-api"></a>

Nachdem Sie Ihre WebSocket API bereitgestellt haben, können Client-Anwendungen eine Verbindung zu ihr herstellen und Nachrichten an sie senden — und Ihr Back-End-Dienst kann Nachrichten an verbundene Client-Anwendungen senden:
+ Sie können `wscat` damit eine Verbindung zu Ihrer WebSocket API herstellen und Nachrichten an sie senden, um das Verhalten von Clients zu simulieren. Siehe [Wird verwendet`wscat`, um eine Verbindung zu einer WebSocket API herzustellen und Nachrichten an diese zu senden](apigateway-how-to-call-websocket-api-wscat.md).
+ Sie können die @connections-API aus Ihrem Backend-Service verwenden, um eine Rückrufnachricht an einen verbundenen Client zu senden, Verbindungsinformationen anzufordern oder die Clientverbindung zu trennen. Siehe [Verwenden der `@connections`-Befehle in Ihrem Backend-Service](apigateway-how-to-call-websocket-api-connections.md).
+ Eine Client-Anwendung kann ihre eigene WebSocket Bibliothek verwenden, um Ihre WebSocket API aufzurufen.

# Wird verwendet`wscat`, um eine Verbindung zu einer WebSocket API herzustellen und Nachrichten an diese zu senden
<a name="apigateway-how-to-call-websocket-api-wscat"></a>

Das `[wscat](https://www.npmjs.com/package/wscat)` Hilfsprogramm ist ein praktisches Tool zum Testen einer WebSocket API, die Sie in API Gateway erstellt und bereitgestellt haben. Sie können `wscat` wie folgt installieren und verwenden:

1. `wscat`Von [https://www.npmjs.com/package/wscat](https://www.npmjs.com/package/wscat) herunterladen.

1. Installieren Sie `wscat` mit dem folgenden Befehl:

   ```
   npm install -g wscat
   ```

1. Um eine Verbindung mit Ihrer API herzustellen, führen Sie wie im folgenden Beispiel gezeigt den Befehl `wscat` aus. Beachten Sie, dass in diesem Beispiel davon ausgegangen wird, dass die `Authorization`-Einstellung `NONE` lautet.

   ```
   wscat -c wss://aabbccddee.execute-api.us-east-1.amazonaws.com/test/
   ```

   Sie müssen `aabbccddee` durch die tatsächliche API-ID ersetzen, die in der API-Gateway-Konsole angezeigt oder vom AWS CLI -Befehl [https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html) zurückgegeben wird.

   Wenn sich Ihre API in einer anderen Region als `us-east-1` befindet, müssen Sie diese außerdem durch die korrekte Region ersetzen.

1. Zum Testen Ihrer API geben Sie eine Nachricht ähnlich der folgenden ein, während Sie noch verbunden sind:

   ```
   {"{jsonpath-expression}":"{route-key}"}
   ```

   wo *\$1jsonpath-expression\$1* ist ein JSONPath Ausdruck und *\$1route-key\$1* ein Routenschlüssel für die API. Beispiel:

   ```
   {"action":"action1"}
   {"message":"test response body"}
   ```

   Weitere Informationen zu JSONPath, finden Sie unter [JSONPath](https://goessner.net/articles/JsonPath/)oder [JSONPath für Java](https://github.com/json-path/JsonPath).

1. Um die Verbindung mit der API zu trennen, geben Sie ei `ctrl-C`.

# Verwenden der `@connections`-Befehle in Ihrem Backend-Service
<a name="apigateway-how-to-call-websocket-api-connections"></a>

Ihr Back-End-Dienst kann die folgenden WebSocket HTTP-Verbindungsanfragen verwenden, um eine Rückrufnachricht an einen verbundenen Client zu senden, Verbindungsinformationen abzurufen oder die Verbindung zum Client zu trennen.

**Wichtig**  
Da für diese Anfragen die [IAM-Autorisierung](apigateway-websocket-control-access-iam.md) erforderlich ist, müssen Sie sich mit [Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html) anmelden. Dazu können Sie die API Gateway-Verwaltungs-API verwenden. Weitere Informationen finden Sie unter [ApiGatewayManagementApi](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/apigatewaymanagementapi.html).

Im folgenden Befehl müssen Sie ihn durch die tatsächliche API-ID `{api-id}` ersetzen, die in der API Gateway Gateway-Konsole angezeigt oder vom Befehl AWS CLI [create-api](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html) zurückgegeben wird. Die Verbindung muss hergestellt werden, bevor Sie diesen Befehl ausführen können. 

Um eine Rückrufnachricht zum Client zu senden, verwenden Sie Folgendes:

```
POST https://{api-id}.execute-api.us-east-1.amazonaws.com/{stage}/@connections/{connection_id}
```

Sie können diese Anforderung mithilfe von `[Postman](https://www.postman.com/)` oder durch Aufruf von `[awscurl](https://github.com/okigan/awscurl)` wie im folgenden Beispiel testen:

```
awscurl --service execute-api -X POST -d "hello world" https://{prefix}.execute-api.us-east-1.amazonaws.com/{stage}/@connections/{connection_id}
```

Sie müssen den Befehl wie im folgenden Beispiel URL-codieren:

```
awscurl --service execute-api -X POST -d "hello world" https://aabbccddee.execute-api.us-east-1.amazonaws.com/prod/%40connections/R0oXAdfD0kwCH6w%3D
```

Zum Abrufen des neuesten Verbindungsstatus des Clients verwenden Sie:

```
GET https://{api-id}.execute-api.us-east-1.amazonaws.com/{stage}/@connections/{connection_id}
```

Zum Trennen der Verbindung mit dem Client verwenden Sie:

```
DELETE https://{api-id}.execute-api.us-east-1.amazonaws.com/{stage}/@connections/{connection_id}
```

Sie können mittels der `$context`-Variablen in Ihrer Integration eine Rückruf-URL dynamisch erstellen. Wenn Sie zum Beispiel die Lambda-Proxy-Integration mit einer `Node.js`-Lambda-Funktion verwenden, können Sie die URL wie folgt aufbauen und eine Nachricht an einen verbundenen Client senden:

```
import {
  ApiGatewayManagementApiClient,
  PostToConnectionCommand,
} from "@aws-sdk/client-apigatewaymanagementapi";

export const handler = async (event) => {
  const domain = event.requestContext.domainName;
  const stage = event.requestContext.stage;
  const connectionId = event.requestContext.connectionId;
  const callbackUrl = `https://${domain}/${stage}`;
  const client = new ApiGatewayManagementApiClient({ endpoint: callbackUrl });

  const requestParams = {
    ConnectionId: connectionId,
    Data: "Hello!",
  };

  const command = new PostToConnectionCommand(requestParams);

  try {
    await client.send(command);
  } catch (error) {
    console.log(error);
  }

  return {
    statusCode: 200,
  };
};
```

Wenn Sie einen benutzerdefinierten Domainnamen für Ihre WebSocket API verwenden, entfernen Sie die `stage` Variable aus Ihrem Funktionscode.

Wenn Sie eine Rückrufnachricht senden, muss Ihre Lambda-Funktion über die Berechtigung verfügen, die API-Gateway-Management-API aufzurufen. Möglicherweise erhalten Sie eine Fehlermeldung mit dem Inhalt `GoneException`, wenn Sie eine Nachricht veröffentlichen, bevor die Verbindung hergestellt wurde oder nachdem der Client die Verbindung getrennt hat. 