Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Vue d'ensemble de WebSocket APIs in API Gateway
Dans API Gateway, vous pouvez créer une WebSocket API en tant que frontend dynamique pour un AWS service (tel que Lambda ou DynamoDB) ou pour un point de terminaison HTTP. L' WebSocket API appelle votre backend en fonction du contenu des messages qu'il reçoit des applications clientes.
Contrairement à une API REST, qui reçoit et répond aux demandes, une WebSocket API prend en charge la communication bidirectionnelle entre les applications clientes et votre backend. Le serveur principal peut envoyer des messages de rappel aux clients connectés.
Dans votre WebSocket API, les messages JSON entrants sont dirigés vers les intégrations du backend en fonction des routes que vous configurez. (Les messages non JSON sont dirigés vers une route `$default` que vous configurez.)
Une *route* comprend une *clé de routage*, qui correspond à la valeur attendue une fois qu’une *expression de sélection de la route* est évaluée. L’attribut `routeSelectionExpression` est défini au niveau de l’API. Il spécifie une propriété JSON attendue dans la charge utile du message. Pour plus d’informations sur les expressions de sélection de la route, consultez la section [Expressions de sélection de la route](websocket-api-develop-routes.md#apigateway-websocket-api-route-selection-expressions).
Par exemple, si vos messages JSON contiennent une propriété `action` et que vous souhaitez effectuer différentes actions en fonction de cette propriété, votre expression de sélection de la route peut être `${request.body.action}`. Votre table de routage spécifie l’action à exécuter en mettant en correspondance la valeur de la propriété `action` avec les valeurs des clés de routage personnalisées que vous avez définies dans la table.
## Utiliser des routes pour une WebSocket API
Trois routes prédéfinies peuvent être utilisées : `$connect`, `$disconnect` et `$default`. De plus, vous pouvez créer des routes personnalisées.
+ API Gateway appelle la `$connect` route lorsqu'une connexion persistante entre le client et une WebSocket API est initiée.
+ API Gateway appelle la route `$disconnect` lorsque le client ou le serveur se déconnecte de l’API.
+ API Gateway appelle une route personnalisée après évaluation de l’expression de sélection de la route par rapport au message si une route correspondante est trouvée ; la correspondance détermine l’intégration appelée.
+ API Gateway appelle la route `$default` si l’expression de sélection de la route ne peut pas être évaluée par rapport au message ou si aucune route correspondante n’est trouvée.
Pour plus d’informations sur les routes `$connect` et `$disconnect`, consultez la section [Gestion des utilisateurs et des applications client connectées : routes `$connect` et `$disconnect`](apigateway-websocket-api-route-keys-connect-disconnect.md).
Pour plus d’informations sur la route `$default` et les routes personnalisées, consultez la section [Invocation de votre intégration backend à l’aide de la route `$default` et de routes personnalisées dans API Gateway](apigateway-websocket-api-routes-integrations.md).
## Envoi de données à des applications client connectées
Les services backend peuvent envoyer des données vers des applications client connectées. Vous pouvez envoyer des données en procédant de la façon suivante :
+ Utilisez une intégration pour envoyer une réponse, qui est renvoyée au client par une réponse de routage que vous avez définie.
+ Vous pouvez utiliser l’API `@connections` pour envoyer une demande POST. Pour de plus amples informations, veuillez consulter [Utilisation des commandes `@connections` dans votre service backend](apigateway-how-to-call-websocket-api-connections.md).
## WebSocket Codes d'état de l'API
API Gateway WebSocket APIs utilise les codes d'état suivants pour les communications entre le serveur et le client, comme décrit dans le [registre des numéros de code de WebSocket fermeture](https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number) :
1001
API Gateway renvoie ce code d’état lorsque le client est inactif pendant 10 minutes ou a atteint la durée maximale de connexion de 2 heures.
1003
API Gateway renvoie ce code d’état lorsqu’un point de terminaison reçoit un type de médias binaires. Les types de médias binaires ne sont pas pris en charge pour WebSocket APIs.
1005
API Gateway renvoie ce code d’état si le client envoie un frame de fermeture sans code de fermeture.
1006
API Gateway renvoie ce code d'état en cas de fermeture inattendue de la connexion, telle que la fermeture de la connexion TCP sans cadre de WebSocket fermeture.
1008
API Gateway renvoie ce code d’état lorsqu’un point de terminaison reçoit un trop grand nombre de demandes d’un client en particulier.
1009
API Gateway renvoie ce code d’état lorsqu’un point de terminaison reçoit un message trop volumineux pour être traité.
1011
API Gateway renvoie ce code d’état en cas d’erreur interne du serveur.
1012
API Gateway renvoie ce code d’état si le service redémarre.
# Gestion des utilisateurs et des applications client connectées : routes `$connect` et `$disconnect`
La section suivante décrit comment utiliser les `$disconnect` routes `$connect` et pour votre WebSocket API.
**Topics**
+ [Route `$connect`](#apigateway-websocket-api-routes-about-connect)
+ [Transmission des informations de connexion depuis la route `$connect`](#apigateway-websocket-api-passing-connectionId-on-connect)
+ [Route `$disconnect`](#apigateway-websocket-api-routes-about-disconnect)
## Route `$connect`
Les applications clientes se connectent à votre WebSocket API en envoyant une demande de WebSocket mise à niveau. Si la demande aboutit, la route `$connect` est exécutée pendant l’établissement de la connexion.
Comme il s'agit d'une connexion dynamique, vous pouvez configurer l'autorisation uniquement sur l'`$connect`itinéraire. WebSocket `AuthN`/ne `AuthZ` sera effectué qu'au moment de la connexion.
Tant que l’exécution de l’intégration associée à la route `$connect` n’est pas terminée, la demande est en attente de mise à niveau et la connexion n’est pas établie. Si la demande `$connect` échoue (par exemple, en raison de l’échec de `AuthN`/`AuthZ` ou de l’intégration), la connexion ne sera pas établie.
**Note**
Si l’autorisation échoue sur `$connect`, la connexion ne sera pas établie, et le client recevra une réponse `401` ou `403`.
La configuration d’une intégration pour `$connect` est facultative. Vous devez envisager la configuration d’une intégration `$connect` dans les cas suivants :
+ Vous souhaitez permettre aux clients de spécifier des sous-protocoles à l’aide du champ `Sec-WebSocket-Protocol`. Pour obtenir un exemple de code, consultez [Configurer un `$connect` itinéraire qui nécessite un WebSocket sous-protocole](websocket-connect-route-subprotocol.md).
+ Vous souhaitez être averti lorsque des clients se connectent.
+ Vous souhaitez limiter les connexions ou contrôler qui se connecte.
+ Vous voulez que votre serveur principal renvoie des messages aux clients à l’aide d’une URL de rappel.
+ Vous souhaitez stocker chaque ID de connexion et d’autres informations dans une base de données (par exemple, Amazon DynamoDB).
## Transmission des informations de connexion depuis la route `$connect`
Vous pouvez utiliser des intégrations de proxy et autres que de proxy pour transmettre les informations de la route `$connect` vers une base de données ou un autre Service AWS.
### Pour transmettre les informations de connexion en utilisant une intégration de proxy
Vous pouvez accéder aux informations de connexion d’une intégration proxy Lambda dans l’événement. Utilisez une autre AWS Lambda fonction Service AWS ou une autre pour publier sur la connexion.
La fonction Lambda suivante montre comment utiliser l’objet `requestContext` pour enregistrer l’ID de connexion, le nom de domaine, le nom d’étape et les chaînes de requête dans un journal.
------
#### [ 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}
```
------
### Pour transmettre les informations de connexion en utilisant une intégration autre que de proxy
+ Vous pouvez accéder aux informations de connexion avec une intégration autre que de proxy. Configurez la demande d'intégration et fournissez un modèle de demande d' WebSocket API. Le modèle de mappage [VTL (Velocity Template Language)](https://velocity.apache.org/engine/devel/vtl-reference.html) suivant fournit une demande d’intégration. Cette demande envoie les informations suivantes à une intégration autre que de proxy :
+ ID de connexion
+ Nom de domaine
+ Nom de l’environnement
+ Chemin
+ En-têtes
+ Chaînes de requête
Cette demande envoie l’ID de connexion, le nom de domaine, le nom d’étape, les chemins, les en-têtes et les chaînes de requête à une intégration autre que de proxy.
```
{
"connectionId": "$context.connectionId",
"domain": "$context.domainName",
"stage": "$context.stage",
"params": "$input.params()"
}
```
Pour obtenir plus d’informations sur la configuration des transformations de données, consultez [Transformations de données pour WebSocket APIs dans API Gateway](websocket-api-data-transformations.md).
Pour terminer la demande d’intégration, définissez `StatusCode: 200` pour la réponse d’intégration. Pour en savoir plus sur la configuration d’une réponse d’intégration, consultez [Configuration d’une réponse d’intégration à l’aide de la console API Gateway](apigateway-websocket-api-integration-responses.md#apigateway-websocket-api-integration-response-using-console).
## Route `$disconnect`
La route `$disconnect` est exécutée une fois que la connexion est fermée.
La connexion peut être fermée par le serveur ou par le client. Comme la connexion est déjà fermée lorsqu’elle est exécutée, `$disconnect` est un événement exécuté au mieux de ce qui est possible. API Gateway fera de son mieux pour fournir l’événement `$disconnect` à votre intégration, mais il ne peut pas garantir sa fourniture.
Le serveur principal peut lancer la déconnexion à l’aide de l’API `@connections`. Pour de plus amples informations, veuillez consulter [Utilisation des commandes `@connections` dans votre service backend](apigateway-how-to-call-websocket-api-connections.md).
# Invocation de votre intégration backend à l’aide de la route `$default` et de routes personnalisées dans API Gateway
La section suivante décrit comment invoquer votre intégration principale à l'aide de la `$default` route ou d'une route personnalisée pour une WebSocket API.
**Topics**
+ [Utilisation de routes pour traiter les messages](#apigateway-websocket-api-overview-routes)
+ [Route `$default`](#apigateway-websocket-api-routes-about-default)
+ [Routes personnalisées](#apigateway-websocket-api-routes-about-custom)
+ [Utilisation des intégrations WebSocket d'API API Gateway pour vous connecter à votre logique métier](#apigateway-websocket-api-overview-integrations)
+ [Différences importantes entre WebSocket APIs et REST APIs](#apigateway-websocket-api-overview-integrations-differences)
## Utilisation de routes pour traiter les messages
Dans API Gateway WebSocket APIs, les messages peuvent être envoyés du client à votre service principal et vice versa. Contrairement au request/response modèle HTTP, WebSocket le backend peut envoyer des messages au client sans que celui-ci n'entreprenne aucune action.
Les messages peuvent être de type JSON ou autre que JSON. Toutefois, seuls les messages JSON peuvent être acheminés vers des intégrations spécifiques en fonction du contenu du message. Les messages autres que JSON sont transmis au serveur principal par la route `$default`.
**Note**
API Gateway prend en charge des charges utiles de messages jusqu’à 128 Ko, avec une taille de trame maximale de 32 Ko. Si un message dépasse 32 Ko, vous devez le diviser en plusieurs trames, chacune de 32 Ko ou moins. Si un message (ou trame) plus grand est reçu, la connexion se ferme avec le code 1009.
À l’heure actuelle, les charges utiles binaires ne sont pas prises en charge. Si une trame binaire est reçue, la connexion se ferme avec le code 1003. Il est toutefois possible de convertir les charges utiles binaires en texte. Voir [Types de supports binaires pour les API WebSocket dans API Gateway](websocket-api-develop-binary-media-types.md).
Avec WebSocket APIs API Gateway, les messages JSON peuvent être routés pour exécuter un service principal spécifique en fonction du contenu du message. Lorsqu'un client envoie un message via sa WebSocket connexion, cela entraîne une *demande de route* vers l' WebSocket API. La demande est mise en correspondance avec la route à l’aide de la clé de routage correspondante dans API Gateway. Vous pouvez configurer une demande de route pour une WebSocket API dans la console API Gateway, à l'aide du AWS CLI ou à l'aide d'un AWS SDK.
**Note**
Dans le AWS CLI and AWS SDKs, vous pouvez créer des itinéraires avant ou après avoir créé des intégrations. À l’heure actuelle, la console ne prend pas en charge la réutilisation d’intégrations. Par conséquent, vous devez d’abord créer la route, puis l’intégration pour cette route.
Vous pouvez configurer API Gateway afin qu’il exécute la validation d’une demande de routage avant de continuer avec la demande d’intégration. Si la validation échoue, API Gateway échoue à la demande sans appeler votre backend, envoie une réponse de `"Bad request body"` passerelle similaire à la suivante au client et publie les résultats de la validation dans CloudWatch Logs :
```
{"message" : "Bad request body", "connectionId": "{connectionId}", "messageId": "{messageId}"}
```
Cela réduit les appels inutiles à votre serveur principal et vous permet de vous concentrer sur les autres exigences de votre API.
Vous pouvez également définir une réponse de routage pour les routes de votre API afin d’activer la communication bidirectionnelle. Une réponse de routage indique quelles données seront envoyées à votre client à la fin de l’intégration d’une route particulière. Il n’est pas nécessaire de définir une réponse pour une route si, par exemple, vous souhaitez qu’un client envoie des messages à votre serveur principal sans recevoir de réponse (communication unidirectionnelle). Toutefois, si vous ne fournissez pas de réponse de routage, API Gateway ne renverra aucune information sur le résultat de votre intégration à vos clients.
## Route `$default`
Chaque API WebSocket API Gateway peut avoir un `$default` itinéraire. Il s’agit d’une valeur de routage spéciale qui peut être utilisée de différentes manières :
+ Vous pouvez l’utiliser conjointement avec les clés de routage définies, pour spécifier une route « de secours » (par exemple, une intégration fictive générique qui renvoie un message d’erreur spécifique) pour des messages entrants qui ne correspondent à aucune des clés de routage définies.
+ Vous pouvez l’utiliser sans clés de routage définies pour spécifier un modèle de proxy qui délègue le routage à un composant backend.
+ Vous pouvez l’utiliser pour spécifier une route pour des charges utiles autres que JSON.
## Routes personnalisées
Si vous souhaitez invoquer une intégration spécifique sur la base du contenu du message, vous pouvez le faire en créant une route personnalisée.
Une route personnalisée utilise une clé de routage et l’intégration que vous spécifiez. Lorsqu’un message entrant contient une propriété JSON et que cette propriété équivaut à une valeur correspondant à celle de la clé de routage, API Gateway appelle l’intégration. (Pour plus d’informations, consultez [Vue d'ensemble de WebSocket APIs in API Gateway](apigateway-websocket-api-overview.md).)
Par exemple, supposons que vous vouliez créer une application de conversation. Vous pouvez commencer par créer une WebSocket API dont l'expression de sélection d'itinéraire est`$request.body.action`. Vous pouvez ensuite définir deux routes : `joinroom` et `sendmessage`. Une application client peut invoquer la route `joinroom` en envoyant un message similaire au suivant :
```
{"action":"joinroom","roomname":"developers"}
```
Elle peut également invoquer la route `sendmessage` en envoyant un message similaire au suivant :
```
{"action":"sendmessage","message":"Hello everyone"}
```
## Utilisation des intégrations WebSocket d'API API Gateway pour vous connecter à votre logique métier
Après avoir configuré un itinéraire pour une API WebSocket API Gateway, vous devez spécifier l'intégration que vous souhaitez utiliser. Comme pour une route, qui peut faire l’objet d’une demande et d’une réponse de routage, une intégration peut être associée à une *demande d’intégration* et à une *réponse d’intégration*. Une *demande d’intégration* contient les informations attendues par votre serveur principal pour traiter la demande provenant de votre client. Une *réponse d’intégration* contient les données que votre backend renvoie à API Gateway, et qui peuvent être utilisées pour construire un message à envoyer au client (si une réponse de routage est définie).
Pour plus d’informations sur la configuration d’intégrations, consultez la section [Intégrations pour WebSocket APIs in API Gateway](apigateway-websocket-api-integrations.md).
## Différences importantes entre WebSocket APIs et REST APIs
Les intégrations pour WebSocket APIs sont similaires aux intégrations pour REST APIs, à l'exception des différences suivantes :
+ Actuellement, dans la console API Gateway, vous devez d’abord créer une route, puis une intégration en tant que cible de cette route. En revanche, dans l’API et l’interface de ligne de commande, vous pouvez créer des routes et des intégrations en toute indépendance et dans n’importe quel ordre.
+ Vous pouvez utiliser une même intégration pour plusieurs routes. Par exemple, si vous avez un ensemble d’actions étroitement liées entre elles, vous souhaiterez peut-être intégrer toutes ces routes dans une Fonction Lambda unique. Au lieu de définir les détails de l’intégration plusieurs fois, vous pouvez spécifier celle-ci une seule fois et l’affecter à chacune des routes connexes.
**Note**
À l’heure actuelle, la console ne prend pas en charge la réutilisation d’intégrations. Par conséquent, vous devez d’abord créer la route, puis l’intégration pour cette route.
Dans le AWS CLI et AWS SDKs, vous pouvez réutiliser une intégration en définissant la cible de l'itinéraire sur une valeur de`"integrations/{integration-id}"`, où `{integration-id}"` est l'identifiant unique de l'intégration à associer à l'itinéraire.
+ API Gateway propose plusieurs [expressions de sélection](apigateway-websocket-api-selection-expressions.md), que vous pouvez utiliser dans vos routes et intégrations. Vous n’avez pas besoin de vous appuyer sur le type de contenu pour sélectionner un modèle d’entrée ou un mappage de sortie. De même que pour les expressions de sélection de la route, vous pouvez définir une expression de sélection qui sera évaluée par API Gateway afin de choisir l’élément adéquat. si aucun modèle correspondant n’est trouvé, le modèle `$default` est utilisé.
+ Dans les demandes d’intégration, l’expression de sélection du modèle prend en charge `$request.body.` et les valeurs statiques.
+ Dans les réponses d’intégration, l’expression de sélection du modèle prend en charge `$request.body.`, `$integration.response.statuscode`, `$integration.response.header.` et les valeurs statiques.
Dans le protocole HTTP, dans lequel les demandes et les réponses sont envoyées de manière synchrone, la communication est essentiellement unidirectionnelle. Dans le WebSocket protocole, la communication est bidirectionnelle. Les réponses sont asynchrones et ne sont pas nécessairement reçues par le client dans l’ordre où les messages du client ont été envoyés. De plus, le serveur principal peut envoyer des messages au client.
**Note**
Pour une route qui est configurée pour utiliser l’intégration `AWS_PROXY` ou `LAMBDA_PROXY`, la communication est unidirectionnelle et API Gateway ne transmet pas automatiquement la réponse du backend par le biais de la réponse de routage. Par exemple, dans le cas de l’intégration `LAMBDA_PROXY`, le corps de message renvoyé par la fonction Lambda n’est pas renvoyé au client. Si vous voulez que le client reçoive les réponses de l’intégration, vous devez définir une réponse de routage pour permettre la communication bidirectionnelle.
# WebSocket expressions de sélection
API Gateway utilise des expressions de sélection pour évaluer le contexte de demande et de réponse, et générer une clé. La clé est ensuite utilisée pour effectuer une sélection parmi un ensemble de valeurs possibles, généralement fournies par vous, en tant que développeur de l’API. L’ensemble exact des variables prises en charge varie en fonction de l’expression en question. Les différentes expressions sont présentées plus en détail ci-après.
Pour toutes les expressions, le langage suit le même ensemble de règles :
+ Une variable est précédée du préfixe `"$"`.
+ Des accolades peuvent être utilisées pour définir explicitement les limites des variables (par exemple., `"${request.body.version}-beta"`.
+ Plusieurs variables sont prises en charge, mais l’évaluation n’intervient qu’une seule fois (pas d’évaluation récursive).
+ L’échappement du symbole du dollar (`$`) est effectué avec `"\"`. C’est particulièrement utile lorsque vous définissez une expression qui est mappée à la clé `$default` réservée (par exemple, `"\$default"`).
+ Dans certains cas, un format de modèle est requis. Dans ce cas, l’expression doit être encapsulée avec des barres obliques (`"/"`) (par exemple, `"/2\d\d/"`) pour correspondre aux codes de statut `2XX`.
**Topics**
+ [Expressions de sélection de la réponse de routage](#apigateway-websocket-api-route-response-selection-expressions)
+ [Expressions de sélection de la clé d’API](#apigateway-websocket-api-apikey-selection-expressions)
+ [Expressions de sélection du mappage d’API](#apigateway-websocket-api-mapping-selection-expressions)
+ [WebSocket résumé de l'expression de sélection](#apigateway-websocket-api-selection-expression-table)
## Expressions de sélection de la réponse de routage
Une [réponse de routage](apigateway-websocket-api-route-response.md) est utilisée pour modéliser une réponse du serveur principal au client. En effet WebSocket APIs, une réponse d'itinéraire est facultative. Une fois défini, il indique à API Gateway qu'il doit renvoyer une réponse à un client à la réception d'un WebSocket message.
L’évaluation de l’*expression de sélection de la réponse de routage* génère une clé de réponse de routage. Au final, cette clé est utilisée pour choisir l’un des éléments [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) associés à l’API. Cependant, à l’heure actuelle, seule la clé `$default` est prise en charge.
## Expressions de sélection de la clé d’API
Cette expression est évaluée lorsque le service détermine que la demande en question doit continuer uniquement si le client fournit une [clé d’API](api-gateway-basic-concept.md#apigateway-definition-api-key).
À l’heure actuelle, les seules deux valeurs prises en charge sont `$request.header.x-api-key` et `$context.authorizer.usageIdentifierKey`.
## Expressions de sélection du mappage d’API
Cette expression est évaluée pour déterminer quelle étape d’API est sélectionnée lorsqu’une demande est effectuée à l’aide d’un domaine personnalisé.
À l'heure actuelle, la seule valeur prise en charge est `$request.basepath`.
## WebSocket résumé de l'expression de sélection
Le tableau suivant récapitule les cas d'utilisation des expressions de sélection dans WebSocket APIs :
| Expression de sélection | Correspond à la clé pour | Remarques | Exemple de cas d’utilisation |
| --- | --- | --- | --- |
| Api.RouteSelectionExpression | Route.RouteKey | \$1default est pris en charge en tant que route fourre-tout. | WebSocket Acheminez les messages en fonction du contexte d'une demande du client. |
| Route.ModelSelectionExpression | Clé pour Route.RequestModels | Facultatif. Si elle est fournie pour une intégration autre que de proxy, la validation du modèle a lieu. `$default` est pris en charge en tant que fourre-tout. | Effectuer une validation de demande de manière dynamique au sein de la même route. |
| Integration.TemplateSelectionExpression | Clé pour Integration.RequestTemplates | Facultatif. Peut être fournie pour une intégration autre que de proxy pour manipuler des charges utiles entrantes. `${request.body.jsonPath}` et les valeurs statiques sont prises en charge. `$default` est pris en charge en tant que fourre-tout. | Manipuler la demande de l’appelant en fonction des propriétés dynamiques de la demande. |
| Integration.IntegrationResponseSelectionExpression | IntegrationResponse.IntegrationResponseKey | Facultatif. Peut être fournie pour une intégration autre que de proxy. Agit en tant que modèle de correspondance pour des messages d’erreur (à partir de Lambda) ou des codes d’état (à partir d’intégrations HTTP). `$default` est obligatoire pour des intégrations autres que de proxy pour agir en tant que fourre-tout pour les réponses fructueuses. | Manipuler la réponse du serveur principal. Choisir l’action à exécuter en fonction de la réponse dynamique du serveur principal (par exemple, traitement distinctif de certaines erreurs). |
| IntegrationResponse.TemplateSelectionExpression | Clé pour IntegrationResponse.ResponseTemplates | Facultatif. Peut être fournie pour une intégration autre que de proxy. \$1default est pris en charge. | Dans certains cas, une propriété dynamique de la réponse peut imposer différentes transformations au sein de la même route et de l’intégration associée. `${request.body.jsonPath}`, `${integration.response.statuscode}`, `${integration.response.header.headerName}`, `${integration.response.multivalueheader.headerName}`, et les valeurs statiques sont prises en charge. `$default` est pris en charge en tant que fourre-tout. |
| Route.RouteResponseSelectionExpression | RouteResponse.RouteResponseKey | Doit être fourni pour initier une communication bidirectionnelle pour un WebSocket itinéraire. À l’heure actuelle, cette valeur est limitée à `$default` uniquement. | |
| RouteResponse.ModelSelectionExpression | Clé pour RouteResponse.RequestModels | Non prise en charge actuellement. | |