Choisir un type d'intégration d’API API Gateway

Vous choisissez un type d'intégration d'API en fonction des types de point de terminaison d'intégration que vous utilisez et de la façon dont vous souhaitez que vos données soient transmises de et vers le point de terminaison d'intégration. Pour une fonction Lambda, vous pouvez avoir l'intégration de proxy Lambda ou l'intégration personnalisée Lambda. Pour un point de terminaison HTTP, vous pouvez avoir l'intégration de proxy HTTP ou l'intégration personnalisée HTTP. Pour une action de service AWS, vous avez l'intégration AWS de type non-proxy uniquement. API Gateway prend également en charge l'intégration fictive, où API Gateway sert de point de terminaison d'intégration pour répondre à une demande de méthode.

L'intégration personnalisée Lambda est un cas particulier de l'intégration AWS, où le point de terminaison d'intégration correspond à l'action d'appel de fonction du service Lambda.

Par programmation, vous choisissez un type d'intégration en définissant la propriété type de la ressource Integration. Pour l'intégration de proxy Lambda, la valeur est AWS_PROXY. Pour l'intégration personnalisée Lambda et toutes les autres intégrations AWS, c'est AWS. Pour l'intégration de proxy HTTP et l'intégration HTTP, la valeur est HTTP_PROXY et HTTP, respectivement. Pour l'intégration fictive, la valeur type est MOCK.

L'intégration de proxy Lambda prend en charge une configuration d'intégration simplifiée avec une seule fonction Lambda. Cette configuration est simple et peut évoluer avec le backend sans besoin de manipuler la configuration existante. Pour ces raisons, il est vivement recommandé d'effectuer l'intégration avec une fonction Lambda.

En revanche, l'intégration personnalisée Lambda permet de réutiliser les modèles de mappage configurés pour divers points de terminaison d'intégration qui ont des exigences similaires de formats de données d'entrée et de sortie. La configuration est plus complexe ; elle est recommandée pour des scénarios d'application plus avancés.

De même, l'intégration de proxy HTTP dispose d'une configuration d'intégration simplifiée et peut évoluer avec le backend sans besoin de manipuler la configuration existante. L'intégration personnalisée HTTP est plus complexe à configurer, mais elle permet de réutiliser les modèles de mappage configurés pour d'autres points de terminaison d'intégration.

La liste suivante récapitule les types d'intégration pris en charge :

• AWS : ce type d'intégration permet à une API d'exposer les actions de service AWS. Dans l'intégration AWS, vous devez configurer à la fois la demande d'intégration et la réponse d'intégration et configurer les mappages de données nécessaires de la demande de méthode à la demande d'intégration et de la réponse d'intégration à la réponse de méthode.

• AWS_PROXY : Ce type d'intégration permet d'intégrer une méthode d'API avec l'action d'appel de fonction Lambda grâce à une configuration d'intégration simplifiée, souple et polyvalente. Cette intégration s'appuie sur les interactions directes entre le client et la fonction Lambda intégrée.

  Avec ce type d'intégration, également appelée intégration de proxy Lambda, vous ne configurez pas la demande d'intégration ou la réponse d'intégration. API Gateway transmet la demande entrante du client comme entrée à la fonction Lambda de backend. La fonction Lambda intégrée prend l'entrée de ce format et analyse l'entrée de tous les sources disponibles, y compris les en-têtes de demande, les variables d'URL de chemin, les paramètres des chaînes de requête et le corps correspondants. La fonction renvoie le résultat respectant ce format de sortie.

  Il s'agit du type d'intégration privilégié pour appeler une fonction Lambda via API Gateway. Il ne correspond à aucune autre action de service AWS, y compris les actions Lambda autres que l'action d'appel de fonction.

• HTTP : ce type d'intégration permet à une API d'exposer les points de terminaison HTTP du backend. Avec l'intégration HTTP, également appelée intégration personnalisée HTTP, vous devez configurez pas la demande d'intégration et la réponse d'intégration. Vous devez configurer les mappages de données nécessaires de la demande de méthode à la demande d'intégration et de la réponse d'intégration à la réponse de méthode.

• HTTP_PROXY: L'intégration de proxy HTTP permet à un client d'accéder aux points de terminaison HTTP du backend avec une configuration d'intégration rationalisée sur une seule méthode d'API. Vous ne définissez pas la demande d'intégration ou la réponse d'intégration. API Gateway transmet la demande entrante du client vers le point de terminaison HTTP et transmet la réponse sortante du point de terminaison HTTP au client.

• MOCK : ce type d'intégration permet à API Gateway de renvoyer une réponse sans envoyer la demande au backend. Cela est utile pour le test d'API, car le code peut être utilisé pour tester la configuration de l'intégration sans encourir des frais pour l'utilisation du backend et pour permettre le développement collaboratif d'une API.

  Dans le cadre du développement collaboratif, une équipe peut isoler ses efforts de développement en configurant des simulations de composants d'API détenus par d'autres équipes en utilisant les intégrations MOCK. Cela permet également de renvoyer les en-têtes CORS et de s'assurer que la méthode d'API autorise l'accès CORS. De fait, la console API Gateway intègre la méthode OPTIONS pour prendre en charge CORS avec une intégration fictive. Les réponses de passerelle sont d'autres exemples d'intégrations fictives.