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. # Überblick über WebSocket APIs in API Gateway In API Gateway können Sie eine WebSocket API als Stateful-Frontend für einen AWS Dienst (wie Lambda oder DynamoDB) oder für einen HTTP-Endpunkt erstellen. Die WebSocket API ruft Ihr Backend auf der Grundlage des Inhalts der Nachrichten auf, die sie von Client-Apps empfängt. Im Gegensatz zu einer REST-API, die Anfragen empfängt und beantwortet, unterstützt eine WebSocket API die bidirektionale Kommunikation zwischen Client-Apps und Ihrem Backend. Das Backend kann Rückruf-Nachrichten an verbundene Clients senden. 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](websocket-api-develop-routes.md#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. ## Verwenden Sie Routen für eine API WebSocket 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. Weitere Informationen über die Routen `$connect` und `$disconnect` finden Sie unter [Verwalten von verbundenen Benutzern und Client-Apps: `$connect`- und `$disconnect`-Routen](apigateway-websocket-api-route-keys-connect-disconnect.md). Weitere Informationen über die Route `$default` und benutzerdefinierte Routen finden Sie unter [Aufrufen Ihrer Backend-Integration mit der `$default`-Route und benutzerdefinierten Routen in API Gateway](apigateway-websocket-api-routes-integrations.md). ## Daten an verbundene Client-Apps senden Backend-Services können Daten an verbundene Client-Apps senden. Gehen Sie für eine Datenversendung wie folgt vor: + Senden Sie eine Antwort mithilfe einer Integration. Diese wird über die von Ihnen definierte Routenantwort an den Client zurückgegeben. + Sie können mithilfe der `@connections`-API eine POST-Anforderung senden. Weitere Informationen finden Sie unter [Verwenden der `@connections`-Befehle in Ihrem Backend-Service](apigateway-how-to-call-websocket-api-connections.md). ## WebSocket API-Statuscodes API Gateway WebSocket APIs verwendet die folgenden Statuscodes für die Kommunikation vom Server zum Client, wie in der [WebSocket Close Code Number Registry](https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number) beschrieben: 1001 API Gateway gibt diesen Statuscode zurück, wenn der Client 10 Minuten inaktiv ist oder die maximale Verbindungsdauer von 2 Stunden erreicht. 1003 API Gateway gibt diesen Statuscode zurück, wenn ein Endpunkt einen binären Medientyp empfängt. Binäre Medientypen werden nicht unterstützt für WebSocket APIs. 1005 API Gateway gibt diesen Statuscode zurück, wenn der Client ein Close-Frame ohne Abschlusscode sendet. 1006 API Gateway gibt diesen Statuscode zurück, wenn die Verbindung unerwartet geschlossen wird, z. B. wenn die TCP-Verbindung ohne einen geschlossenen Frame WebSocket geschlossen wurde. 1008 API Gateway gibt diesen Statuscode zurück, wenn ein Endpunkt zu viele Anfragen von einem bestimmten Client erhält. 1009 API Gateway gibt diesen Statuscode zurück, wenn ein Endpunkt eine Nachricht empfängt, die zu groß ist, um verarbeitet zu werden. 1011 API Gateway gibt diesen Statuscode zurück, wenn ein interner Serverfehler auftritt. 1012 API Gateway gibt diesen Statuscode zurück, wenn der Service neu gestartet wird.