Transformations de données pour WebSocket les API dans API Gateway

Dans API Gateway, la demande de méthode d'une WebSocket API peut prendre une charge utile dans un format différent de la charge utile de la demande d'intégration correspondante, comme l'exige le backend. De même, le backend peut renvoyer une charge utile de réponse d'intégration différente de la charge utile de réponse de méthode attendue par le serveur frontal.

API Gateway vous permet d'utiliser des modèles de mappage pour mapper la charge utile d'une demande de méthode à la demande d'intégration correspondante, et d'une réponse d'intégration à la réponse de méthode correspondante. Vous spécifiez une expression de sélection de modèle pour déterminer le modèle à utiliser afin d'effectuer les transformations de données nécessaires.

Vous pouvez utiliser des mappages de données pour mapper des données d'une demande de routage à une intégration backend. Pour en savoir plus, consultez la section Configurer le mappage des données pour les WebSocket API.

Modèles et modèles de mappage

Un modèle de mappage est un script exprimé en langage VTL (Velocity Template Language) et appliqué à la charge utile à l'aide d'expressions JSONPath. Pour de plus amples informations sur les modèles de mappage API Gateway, veuillez consulter Modèles de mappage pour les API REST.

La charge utile peut comporter un modèle de données en fonction du schéma JSON version 4. Vous n'avez pas besoin de définir un modèle pour créer un modèle de mappage. Toutefois, un modèle peut vous aider à créer un modèle de mappage, car API Gateway génère un plan de modèle en fonction du modèle fourni. Pour de plus amples informations sur les modèles API Gateway, veuillez consulter Modèles de données pour les API REST.

Expressions de sélection du modèle

Pour transformer une charge utile à l'aide d'un modèle de mappage, vous devez spécifier une expression de sélection de modèle d' WebSocket API dans une demande d'intégration ou une réponse d'intégration. Cette expression est évaluée pour déterminer le modèle d'entrée ou de sortie (le cas échéant) à utiliser pour transformer le corps de la demande en corps de demande d'intégration (via un modèle d'entrée) ou le corps de la réponse au corps de la réponse de routage (via un modèle de sortie).

Integration.TemplateSelectionExpression prend en charge ${request.body.jsonPath} et les valeurs statiques.

IntegrationResponse.TemplateSelectionExpression prend en charge ${request.body.jsonPath}, ${integration.response.statuscode}, ${integration.response.header.headerName}, ${integration.response.multivalueheader.headerName} et des valeurs statiques.

Expressions de sélection de la réponse d'intégration

Lorsque vous configurez une réponse d'intégration pour une WebSocket API, vous pouvez éventuellement spécifier une expression de sélection de réponse d'intégration. Cette expression détermine quelle IntegrationResponse doit être sélectionnée lorsqu'une intégration est renvoyée. La valeur de cette expression est actuellement restreinte par API Gateway, comme défini ci-dessous. Gardez à l'esprit que cette expression est uniquement pertinente pour des intégrations autres que de proxy. Une intégration de proxy transmet simplement la charge utile de la réponse à l'appelant sans modélisation ni modification.

Contrairement aux autres expressions de sélection précédentes, cette expression prend actuellement en charge un format de correspondance de modèle. L'expression doit être encapsulée avec des barres obliques.

Actuellement, la valeur est fixée en fonction de l'élément integrationType:

• Pour les intégrations basées sur Lambda, la valeur est $integration.response.body.errorMessage.

• Pour les intégrations HTTP et MOCK, la valeur est $integration.response.statuscode.

• Pour HTTP_PROXY et AWS_PROXY, l'expression n'est pas utilisée, car vous demandez que la charge utile soit transmise à l'appelant.