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. # Verwalten von verbundenen Benutzern und Client-Apps: `$connect`- und `$disconnect`-Routen Im folgenden Abschnitt wird beschrieben, wie Sie die `$connect` und `$disconnect` -Routen für Ihre WebSocket API verwenden. **Topics** + [Die Route `$connect`](#apigateway-websocket-api-routes-about-connect) + [Verbindungsinformationen von der `$connect`-Route übergeben](#apigateway-websocket-api-passing-connectionId-on-connect) + [Die Route `$disconnect`](#apigateway-websocket-api-routes-about-disconnect) ## Die Route `$connect` Client-Apps stellen eine Verbindung zu Ihrer WebSocket API her, indem sie eine WebSocket Upgrade-Anfrage senden. Wenn die Anforderung erfolgreich ist, wird die Route `$connect` ausgeführt, während die Verbindung hergestellt wird. Da es sich bei der WebSocket Verbindung um eine statusbehaftete Verbindung handelt, können Sie die Autorisierung nur für die `$connect` Route konfigurieren. `AuthN`/`AuthZ`wird nur zur Verbindungszeit ausgeführt. Solange die Integration im Zusammenhang mit der Route `$connect` noch nicht abgeschlossen wurde, steht die Upgrade-Anforderung noch an und die tatsächliche Verbindung wird nicht hergestellt. Wenn die `$connect`-Anforderung fehlschlägt (z. B. aufgrund eines `AuthN`/`AuthZ`-Fehlers oder eines Integrationsfehlers), wird die Verbindung nicht hergestellt. **Anmerkung** Wenn die Autorisierung für `$connect` fehlschlägt, wird keine Verbindung hergestellt, und der Client erhält eine `401`- oder `403`-Antwort. Das Einrichten einer Integration für `$connect` ist optional. Sie sollten die Einrichtung einer `$connect`-Integration unter folgenden Umständen erwägen: + Sie möchten Clients ermöglichen, Unterprotokolle mithilfe des `Sec-WebSocket-Protocol`-Felds anzugeben. Beispielcode finden Sie unter [Richten Sie eine `$connect` Route ein, für die ein WebSocket Unterprotokoll erforderlich ist](websocket-connect-route-subprotocol.md). + Sie möchten benachrichtigt werden, wenn Clients verbunden werden. + Wenn Sie Verbindungen drosseln möchten oder wenn Sie steuern möchten, wer eine Verbindung herstellt. + Wenn Sie möchten, dass Ihr Backend über eine Rückruf-URL Nachrichten an Clients zurücksendet. + Sie möchten jede Verbindungs-ID und andere Informationen in einer Datenbank (z. B. Amazon DynamoDB) speichern. ## Verbindungsinformationen von der `$connect`-Route übergeben Sie können sowohl Proxy- als auch Nicht-Proxy-Integrationen verwenden, um Informationen von der `$connect`-Route an eine Datenbank oder einen anderen AWS-Service zu übergeben. ### So übergeben Sie Verbindungsinformationen mithilfe einer Proxy-Integration In diesem Fall können Sie über eine Lambda-Proxy-Integration auf die Verbindungsinformationen zugreifen. Verwenden Sie eine andere AWS-Service AWS Lambda OR-Funktion, um Beiträge an die Verbindung zu senden. Die folgende Lambda-Funktion zeigt, wie das `requestContext`-Objekt verwendet wird, um die Verbindungs-ID, den Domänennamen, den Stufennamen und die Abfragezeichenfolgen zu protokollieren. ------ #### [ Node.js ] ``` export const handler = async(event, context) => { const connectId = event["requestContext"]["connectionId"] const domainName = event["requestContext"]["domainName"] const stageName = event["requestContext"]["stage"] const qs = event['queryStringParameters'] console.log('Connection ID: ', connectId, 'Domain Name: ', domainName, 'Stage Name: ', stageName, 'Query Strings: ', qs ) return {"statusCode" : 200} }; ``` ------ #### [ Python ] ``` import json import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context): connectId = event["requestContext"]["connectionId"] domainName = event["requestContext"]["domainName"] stageName = event["requestContext"]["stage"] qs = event['queryStringParameters'] connectionInfo = { 'Connection ID': connectId, 'Domain Name': domainName, 'Stage Name': stageName, 'Query Strings': qs} logging.info(connectionInfo) return {"statusCode": 200} ``` ------ ### So übergeben Sie Verbindungsinformationen mithilfe einer Nicht-Proxy-Integration + Sie können mit einer Nicht-Proxy-Integration auf die Verbindungsinformationen zugreifen. Richten Sie die Integrationsanfrage ein und stellen Sie eine WebSocket API-Anforderungsvorlage bereit. Die folgende Zuordnungsvorlage der [Velocity Template Language (VTL)](https://velocity.apache.org/engine/devel/vtl-reference.html) enthält eine Integrationsanforderung. Diese Anforderung sendet die folgenden Details an eine Nicht-Proxy-Integration: + Verbindungs-ID + Domainname + Stufenname + Pfad + Kopfzeilen + Abfragezeichenfolgen Diese Anforderung sendet die Verbindungs-ID, den Domain-Namen, den Namen der Phase, die Pfade, Header und Abfragezeichenfolgen an eine Nicht-Proxy-Integration. ``` { "connectionId": "$context.connectionId", "domain": "$context.domainName", "stage": "$context.stage", "params": "$input.params()" } ``` Weitere Informationen zum Einrichten von Datenübertragungen finden Sie unter[Datentransformationen für WebSocket APIs im API Gateway](websocket-api-data-transformations.md). Zum Abschließen der Integrationsanforderung legen Sie die Integrationsantwort `StatusCode: 200` fest. Weitere Informationen zum Einrichten einer Integrationsantwort finden Sie unter [Integrationsantwort mit der API Gateway-Konsole einrichten](apigateway-websocket-api-integration-responses.md#apigateway-websocket-api-integration-response-using-console). ## Die Route `$disconnect` Die Route `$disconnect` wird ausgeführt, nachdem die Verbindung geschlossen wurde. Die Verbindung kann vom Server oder vom Client geschlossen werden. Da die Verbindung bereits geschlossen ist, wenn sie ausgeführt wird, ist `$disconnect` ein "Best Effort"-Ereignis. API Gateway wird sich nach bemühen, das `$disconnect`-Ereignis an Ihre Integration zu übermitteln, kann aber die Übermittlung nicht garantieren. Das Backend kann die Verbindungstrennung mithilfe der `@connections`-API einleiten. Weitere Informationen finden Sie unter [Verwenden der `@connections`-Befehle in Ihrem Backend-Service](apigateway-how-to-call-websocket-api-connections.md). # Aufrufen Ihrer Backend-Integration mit der `$default`-Route und benutzerdefinierten Routen in API Gateway Im folgenden Abschnitt wird beschrieben, wie Sie Ihre Backend-Integration entweder mithilfe der `$default` Route oder einer benutzerdefinierten Route für eine WebSocket API aufrufen. **Topics** + [Verwenden von Routen zur Verarbeitung von Nachrichten](#apigateway-websocket-api-overview-routes) + [Die Route `$default`](#apigateway-websocket-api-routes-about-default) + [Benutzerdefinierte Routen](#apigateway-websocket-api-routes-about-custom) + [Verwenden Sie API Gateway WebSocket API-Integrationen, um eine Verbindung zu Ihrer Geschäftslogik herzustellen](#apigateway-websocket-api-overview-integrations) + [Wichtige Unterschiede zwischen WebSocket APIs und REST APIs](#apigateway-websocket-api-overview-integrations-differences) ## Verwenden von Routen zur Verarbeitung von Nachrichten In API Gateway WebSocket APIs können Nachrichten vom Client an Ihren Backend-Service gesendet werden und umgekehrt. Im Gegensatz zum request/response HTTP-Modell können im Backend Nachrichten an WebSocket den Client gesendet werden, ohne dass der Client etwas unternimmt. Es kann sich dabei um JSON- oder Nicht-JSON-Nachrichten handeln. Es können jedoch nur JSON-Nachrichten basierend auf dem Nachrichteninhalt an bestimmte Integrationen weitergeleitet werden. Nicht-JSON-Nachrichten werden über die `$default`-Route an das Backend übergeben. **Anmerkung** API Gateway unterstützt Nachrichten-Payloads bis zu 128 KB mit einer maximalen Frame-Größe von 32 KB. Sie müssen Nachrichten, die 32 KB überschreiten, in mehrere Frames aufteilen, die jeweils 32 KB oder kleiner sind. Wenn eine größere Nachricht (oder ein größerer Frame) empfangen wird, wird die Verbindung mit dem Code 1009 geschlossen. Derzeit werden keine binären Nutzlasten unterstützt. Wenn ein binärer Frame empfangen wird, wird die Verbindung mit dem Code 1003 geschlossen. Es ist jedoch möglich, binäre Nutzlasten in Text zu konvertieren. Siehe [Binäre Medientypen für WebSocket-APIs in API Gateway](websocket-api-develop-binary-media-types.md). WebSocket APIs In API Gateway können JSON-Nachrichten weitergeleitet werden, um einen bestimmten Backend-Service basierend auf dem Nachrichteninhalt auszuführen. Wenn ein Client eine Nachricht über seine WebSocket Verbindung sendet, führt dies zu einer *Routing-Anfrage* an die WebSocket API. Die Anfrage wird der Route mit dem entsprechenden Routenschlüssel in API Gateway zugeordnet. Sie können eine Routenanforderung für eine WebSocket API in der API Gateway Gateway-Konsole einrichten AWS CLI, indem Sie das oder ein AWS SDK verwenden. **Anmerkung** Im AWS CLI und können Sie Routen erstellen AWS SDKs, bevor oder nachdem Sie Integrationen erstellt haben. Derzeit unterstützt die Konsole keine Wiederverwendung von Integrationen. Daher müssen Sie zuerst die Route erstellen und dann die Integration für diese Route. 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 `"Bad request body"` Gateway-Antwort ähnlich der folgenden an den Client und veröffentlicht die Validierungsergebnisse in CloudWatch Logs: ``` {"message" : "Bad request body", "connectionId": "{connectionId}", "messageId": "{messageId}"} ``` Damit werden unnötige Aufrufe Ihres Backend reduziert, sodass Sie sich auf andere Voraussetzungen für Ihre API konzentrieren können. Darüber hinaus können Sie eine Routenantwort für die Routen Ihrer API vorgeben, um eine bidirektionale Kommunikation zu ermöglichen. Eine Routenantwort beschreibt, welche Daten bei Abschluss der Integration einer bestimmten Route an Ihren Client gesendet werden. Es ist nicht notwendig, eine Antwort für eine Route vorzugeben, wenn ein Client Nachrichten an Ihr Backend senden soll, ohne eine Antwort zu erhalten (unidirektionale Kommunikation). Wenn Sie keine Routenantwort bereitstellen, sendet API Gateway jedoch keine Informationen über das Ergebnis Ihrer Integration an Ihre Kunden. ## Die Route `$default` Jede WebSocket API-Gateway-API kann eine `$default` Route haben. Hierbei handelt es sich um einen speziellen Routing-Wert, der auf folgende Weise eingesetzt werden kann: + Sie können ihn zusammen mit vorgegebenen Routenschlüsseln verwenden, um für eingehende Nachrichten, auf die keine der vorgegebenen Routenschlüssel zutreffen, eine "Fallback"-Route anzugeben (z. B. eine generische Pseudo-Integration, die eine bestimmte Fehlermeldung zurückgibt). + Sie können ihn ohne vorgegebene Routenschlüssel verwenden, um ein Proxy-Modell anzugeben, durch das Routing an eine Backend-Komponente delegiert wird. + Sie können mit ihm eine Route für Nicht-JSON-Nutzlasten angeben. ## Benutzerdefinierte Routen Wenn basierend auf dem Nachrichteninhalt eine bestimmte Integration aufgerufen werden soll, können Sie hierzu eine benutzerdefinierte Route erstellen. Für eine benutzerdefinierte Route werden ein Routenschlüssel und eine Integration nach Ihren Angaben verwendet. Wenn eine eingehende Nachricht eine JSON-Eigenschaft enthält und diese Eigenschaft mit einem Wert ausgewertet wird, der mit dem Routenschlüsselwert übereinstimmt, ruft API Gateway die Integration auf. (Weitere Informationen finden Sie unter [Überblick über WebSocket APIs in API Gateway](apigateway-websocket-api-overview.md).) Angenommen, Sie möchten eine Chat-Raum-Anwendung erstellen. Sie könnten damit beginnen, eine WebSocket API zu erstellen, deren Routenauswahlausdruck lautet`$request.body.action`. Anschließend könnten Sie zwei Routen definieren: `joinroom` und `sendmessage`. Ein Client-App könnte die `joinroom`-Route durch Senden einer Nachricht wie die folgende aufrufen: ``` {"action":"joinroom","roomname":"developers"} ``` Und sie könnte die `sendmessage`-Route durch Senden einer Nachricht wie die folgende aufrufen: ``` {"action":"sendmessage","message":"Hello everyone"} ``` ## Verwenden Sie API Gateway WebSocket API-Integrationen, um eine Verbindung zu Ihrer Geschäftslogik herzustellen Nachdem Sie eine Route für eine WebSocket API-Gateway-API eingerichtet haben, müssen Sie die Integration angeben, die Sie verwenden möchten. Genauso wie eine Route über eine Routenanforderung und eine Routenantwort verfügen kann, kann eine Integration eine *Integrationsanforderung* und eine *Integrationsantwort* besitzen. Eine *Integrationsanforderung* enthält die Informationen, die von Ihrem Backend zur Verarbeitung der von Ihrem Client stammenden Anforderung erwartet werden. Die *Integrationsantwort* enthält die Daten, die Ihr Backend an API Gateway zurücksendet. Sie kann verwendet werden, um eine an den Client zu sendende Nachricht zu verfassen (falls eine Routenantwort definiert ist). Weitere Informationen zum Einrichten von Integrationen finden Sie unter [Integrationen für das WebSocket APIs API Gateway](apigateway-websocket-api-integrations.md). ## Wichtige Unterschiede zwischen WebSocket APIs und REST APIs Integrationen für WebSocket APIs ähneln Integrationen für REST APIs, mit Ausnahme der folgenden Unterschiede: + Derzeit müssen Sie in der API Gateway-Konsole zuerst eine Route und dann eine Integration als Ziel dieser Route erstellen. In der API und der CLI können Sie Routen und Integrationen jedoch unabhängig voneinander in beliebiger Reihenfolge erstellen. + Sie können eine einzelne Integration für mehrere Routen verwenden. Für eine Gruppe von Aktionen, die eng miteinander in Beziehung stehen, empfiehlt es sich beispielsweise, dass alle diese Routen zu einer einzelnen Lambda-Funktion führen. Anstatt die Details der Integration mehrmals zu definieren, können Sie sie einmal angeben und jeder verwandten Route zuweisen. **Anmerkung** Derzeit unterstützt die Konsole keine Wiederverwendung von Integrationen. Daher müssen Sie zuerst die Route erstellen und dann die Integration für diese Route. Im Feld AWS CLI und können Sie eine Integration wiederverwenden AWS SDKs, indem Sie das Ziel der Route auf einen Wert von setzen`"integrations/{integration-id}"`, wobei `{integration-id}"` es sich um die eindeutige ID der Integration handelt, die der Route zugeordnet werden soll. + API Gateway bietet mehrere [Auswahlausdrücke](apigateway-websocket-api-selection-expressions.md), die Sie in Ihren Routen und Integrationen verwenden können. Sie müssen die Auswahl einer Eingabevorlage oder einer Ausgabezuordnung nicht vom Inhaltstyp abhängig machen. Wie bei Routenauswahlausdrücken können Sie einen Auswahlausdruck definieren, der von API Gateway ausgewertet wird, um das richtige Element auszuwählen. Alle von ihnen übernehmen automatisch die `$default`-Vorlage, wenn keine passende Vorlage gefunden wird. + In Integrationsanforderungen unterstützt der Vorlagen-Auswahlausdruck `$request.body.` und statische Werte. + In Integrationsantworten unterstützt der Vorlagen-Auswahlausdruck `$request.body.`, `$integration.response.statuscode` und `$integration.response.header.` sowie statische Werte. Im HTTP-Protokoll, in dem Anforderungen und Antworten synchron gesendet werden, ist die Kommunikation im Wesentlichen unidirektional. Im WebSocket Protokoll erfolgt die Kommunikation in beide Richtungen. Antworten sind asynchron und werden vom Client nicht unbedingt in der gleichen Reihenfolge empfangen, in der die Client-Nachrichten gesendet wurden. Darüber hinaus kann das Backend Nachrichten an den Client senden. **Anmerkung** Für eine Route, die zur Verwendung der Integration `AWS_PROXY` oder `LAMBDA_PROXY` konfiguriert wurde, ist die Kommunikation unidirektional. API Gateway übergibt die Backend-Antwort nicht automatisch über die Routenantwort. Wenn bei der `LAMBDA_PROXY`-Integration wird der von der Lambda-Funktion zurückgegebene Text beispielsweise nicht an den Client zurückgegeben. Wenn Sie möchten, dass der Client Integrationsantworten erhält, müssen Sie eine Routenantwort definieren, um eine bidirektionale Kommunikation zu ermöglichen. # WebSocket Auswahlausdrücke API Gateway verwendet Auswahlausdrücke als Möglichkeit, den Anfrage- und Antwortkontext auszuwerten und einen Schlüssel zu erzeugen. Anhand des Schlüssels wird dann aus einem Satz möglicher Werte ausgewählt, die gewöhnlich von Ihnen, dem API-Entwickler, bereitgestellt werden. Der genaue Satz der unterstützten Variablen ist vom jeweiligen Ausdruck abhängig. Jeder Ausdruck wird nachstehend weiter erörtert. Für alle Ausdrücke folgt die Sprache dem gleichen Satz von Regeln: + Einer Variable wird vorangestell `"$"`. + Variablen können explizit durch geschweifte Klammern abgegrenzt werden, z. ., `"${request.body.version}-beta"`. + Mehrere Variablen werden unterstützt, aber die Auswertung findet nur einmal statt (keine rekursive Auswertung). + Ein Dollarzeichen (`$`) kann durch die Escape-Zeichen `"\"` geschützt werden. Dies ist besonders nützlich, wenn ein Ausdruck definiert wird, der dem reservierten `$default`-Schlüssel zugeordnet wird, z. B. `"\$default"`. + In einigen Fällen ist ein Musterformat erforderlich. In diesem Fall sollte der Ausdruck entsprechend `"/"`-Statuscodes mit Schrägstrichen (`"/2\d\d/"`) verpackt werden, z. B. `2XX`. **Topics** + [Routenantwort-Auswahlausdrücke](#apigateway-websocket-api-route-response-selection-expressions) + [API-Schlüssel-Auswahlausdrücke](#apigateway-websocket-api-apikey-selection-expressions) + [API-Zuordnungs-Auswahlausdrücke](#apigateway-websocket-api-mapping-selection-expressions) + [WebSocket Zusammenfassung des Auswahlausdrucks](#apigateway-websocket-api-selection-expression-table) ## Routenantwort-Auswahlausdrücke Eine [Routenantwort](apigateway-websocket-api-route-response.md) wird für die Modellierung einer Antwort vom Backend zum Client verwendet. Für WebSocket APIs ist eine Routenantwort optional. Wenn es definiert ist, signalisiert es API Gateway, dass es beim Empfang einer WebSocket Nachricht eine Antwort an einen Client zurückgeben soll. Die Auswertung des *Routenantwort-Auswahlausdrucks* ergibt einen Routenantwort-Schlüssel. Zukünftig wird dieser Schlüssel zur Auswahl unter einer der mit der API verknüpften [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid-routeresponses.html](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid-routeresponses.html) dienen. Zurzeit wird jedoch nur der Schlüssel `$default` unterstützt. ## API-Schlüssel-Auswahlausdrücke Dieser Ausdruck wird ausgewertet, wenn der Service bestimmt, dass mit der vorliegenden Anforderung nur fortgefahren werden soll, wenn der Client einen gültigen [API-Schlüssel](api-gateway-basic-concept.md#apigateway-definition-api-key) bereitstellt. Zurzeit werden als einzigen Werte `$request.header.x-api-key` und `$context.authorizer.usageIdentifierKey` unterstützt. ## API-Zuordnungs-Auswahlausdrücke Dieser Ausdruck wird ausgewertet, um zu bestimmen, welche API-Stufe bei einer über eine benutzerdefinierte Domäne gestellten Anforderung auszuwählen ist. Derzeit wird als einziger Wert unterstütz `$request.basepath`. ## WebSocket Zusammenfassung des Auswahlausdrucks In der folgenden Tabelle sind die Anwendungsfälle für Auswahlausdrücke zusammengefasst in WebSocket APIs: | Auswahlausdrücke | Ausgewertet auf Schlüssel für | Hinweise | Beispielanwendungsfall | | --- | --- | --- | --- | | Api.RouteSelectionExpression | Route.RouteKey | \$1default wird als Catch-all-Route unterstützt. | Leitet WebSocket Nachrichten auf der Grundlage des Kontextes einer Client-Anfrage weiter. | | Route.ModelSelectionExpression | Schlüssel für Route.RequestModels | Optional. Bei Angabe für Nicht-Proxy-Integrationen findet eine Modellvalidierung statt. `$default` wird als Catch-all-Route unterstützt. | Führt die Anforderungsvalidierung dynamisch innerhalb derselben Route aus. | | Integration.TemplateSelectionExpression | Schlüssel für Integration.RequestTemplates | Optional. Kann für Nicht-Proxy-Integrationen zum Bearbeiten von eingehenden Nutzlasten bereitgestellt werden. `${request.body.jsonPath}`Unterstützte Werte sind und statische Werte. `$default` wird als Catch-all-Route unterstützt. | Dient zur Bearbeitung der Anforderung der aufrufenden Methode je nach den dynamischen Eigenschaften der Anforderung. | | Integration.IntegrationResponseSelectionExpression | IntegrationResponse.IntegrationResponseKey | Optional. Kann für Nicht-Proxy-Integrationen bereitgestellt werden. Dient als Mustervergleich für Fehlermeldungen (von Lambda) oder Statuscodes (von HTTP-Integrationen). `$default` ist erforderlich, damit Nicht-Proxy-Integrationen als Catch-All für erfolgreiche Antworten fungieren. | Dient zum Bearbeiten der Antwort vom Backend. Wählen Sie, welche Aktion basierend auf der dynamischen Antwort des Backends ausgeführt werden soll (z. B. unterschiedliche Behandlung bestimmter Fehler). | | IntegrationResponse.TemplateSelectionExpression | Schlüssel für IntegrationResponse.ResponseTemplates | Optional. Kann für Nicht-Proxy-Integrationen bereitgestellt werden. \$1default wird unterstützt. | In einigen Fällen kann eine dynamische Eigenschaft der Antwort verschiedene Transformationen innerhalb derselben Route und zugehörigen Integration vorgeben. `${request.body.jsonPath}`, `${integration.response.statuscode}`, `${integration.response.header.headerName}`, `${integration.response.multivalueheader.headerName}`, Unterstützte Werte sind , , , und statische Werte. `$default` wird als Catch-all-Route unterstützt. | | Route.RouteResponseSelectionExpression | RouteResponse.RouteResponseKey | Sollte bereitgestellt werden, um die bidirektionale Kommunikation für eine WebSocket Route zu initiieren. Zurzeit ist dieser Wert ausschließlich auf `$default` eingeschränkt. | | | RouteResponse.ModelSelectionExpression | Schlüssel für RouteResponse.RequestModels | Wird derzeit nicht unterstützt. | |