Configuration des intégrations fictives dans API Gateway - Amazon API Gateway

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.

Configuration des intégrations fictives dans API Gateway

Amazon API Gateway prend en charge les intégrations fictives pour les méthodes API. Cette fonction permet aux développeurs d'API de générer des réponses d'API directement à partir d'API Gateway, sans nécessiter de backend d'intégration. En tant que développeur d'API, vous pouvez utiliser cette fonction pour débloquer les équipes dépendantes qui doivent utiliser une API avant la fin du développement du projet. Vous pouvez également utiliser cette fonction pour mettre en service une page de destination pour votre API, qui peut fournir une présentation de votre API et un accès à cette dernière. Pour obtenir un exemple de page de destination de ce type, consultez la demande et la réponse d'intégration de la méthode GET sur la ressource racine de l'exemple d'API présentées dans Tutoriel : Création d'une API REST par l'importation d'un exemple.

En tant que développeur d'API, vous décidez de la façon dont API Gateway répond à une demande d'intégration fictive. Pour cela, vous configurez la demande d'intégration et la réponse d'intégration de la méthode pour associer une réponse à un code d'état donné. Pour une méthode avec l'intégration fictive permettant de renvoyer une réponse 200, configurez le modèle de mappage du corps de la demande d'intégration pour qu'il renvoie ce qui suit.

{"statusCode": 200}

Configurer une réponse d'intégration 200 pour que le modèle de mappage de corps suivant, par exemple :

{ "statusCode": 200, "message": "Go ahead without me." }

De même, pour que la méthode renvoie, par exemple, une réponse d'erreur 500, configurez le modèle de mappage du corps de la demande d'intégration pour qu'il renvoie ce qui suit.

{"statusCode": 500}

Configurer une réponse d'intégration 500 avec, par exemple, le modèle de mappage de corps suivant :

{ "statusCode": 500, "message": "The invoked method is not supported on the API resource." }

Sinon, vous pouvez obtenir qu'une méthode d'intégration fictive renvoie la réponse d'intégration par défaut sans définir le modèle de mappage de demande d'intégration. La réponse d'intégration par défaut correspond à celle ayant un statut de HTTP status regex non défini. Assurez-vous que les comportements de transfert appropriés sont définis.

Note

les intégrations fictives ne sont pas destinés à prendre en charge des modèles de réponse de grande taille. Si vous en avez besoin pour votre cas d'utilisation, vous devriez plutôt envisager d'utiliser une intégration Lambda.

À l'aide d'un modèle de mappage de demande d'intégration, vous pouvez injecter une logique d'application permettant de choisir la réponse d'intégration fictive à renvoyer selon certaines conditions. Par exemple, vous pouvez utiliser un paramètre de requête scope sur les demandes entrantes pour déterminer s'il faut renvoyer une réponse positive ou une réponse d'erreur :

{ #if( $input.params('scope') == "internal" ) "statusCode": 200 #else "statusCode": 500 #end }

Ainsi, la méthode de l'intégration fictive laisse passer les appels internes tout en rejetant d'autres types d'appels en renvoyant une réponse d'erreur.

Dans cette section, nous décrivons comment utiliser la console API Gateway pour activer l'intégration fictive d'une méthode d'API.