Intégrations : Lambda, HTTP et simulées

Chaque méthode API Gateway nécessite une intégration avec un serveur principal — le système qui traite la requête et renvoie une réponse. API Gateway prend en charge cinq types d’intégration : proxy Lambda, Lambda personnalisé, proxy HTTP, HTTP personnalisé et simulée. Les API HTTP prennent uniquement en charge les proxys Lambda et HTTP. Les API REST prennent en charge les cinq types. Le choix de l’intégration détermine le niveau de contrôle dont vous disposez sur la transformation des requêtes et des réponses.

Avec l’intégration proxy Lambda, API Gateway transmet l’intégralité de la requête HTTP à Lambda sous la forme d’un objet d’événement structuré contenant notamment les en-têtes, les chaînes de requête, les paramètres de chemin, le corps et le contexte. Votre fonction Lambda doit renvoyer un objet de réponse correctement formaté avec statusCode, headers et body. Il s’agit du modèle le plus simple et le plus courant : aucun modèle de mappage n’est nécessaire et votre fonction Lambda contrôle entièrement la réponse.

Avec l’intégration Lambda sans proxy (personnalisée), API Gateway utilise des modèles de mappage (Apache Velocity Template Language, VTL) pour transformer la requête avant de l’envoyer à Lambda, puis transforme la réponse de Lambda avant de la renvoyer au client. Votre fonction Lambda reçoit une charge utile personnalisée et épurée, plutôt que l’événement brut d’API Gateway. Cette approche sépare les aspects liés au transport de la logique métier, mais nécessite de maintenir des modèles VTL. Utilisez une intégration personnalisée lorsque vous souhaitez séparer strictement le contrat entre l’API et le serveur principal.

L’intégration proxy HTTP transmet directement les requêtes à un point de terminaison HTTP externe (il peut s’agir d’une instance EC2, d’un ALB, d’un serveur sur site ou de toute URL publique), sans transformation. API Gateway transmet la requête telle quelle et renvoie la réponse du serveur principal au client. Cette solution est idéale pour faire passer des serveurs REST existants derrière API Gateway afin d’ajouter une limitation du débit, une surveillance et des clés d’API sans modifier le code du serveur principal. Elle prend en charge les serveurs principaux HTTPS avec vérification du certificat.

L’intégration HTTP personnalisée transmet également les requêtes à un point de terminaison HTTP externe, mais utilise des modèles de mappage pour transformer à la fois la requête envoyée au serveur principal et la réponse reçue. Cette solution est utile lorsque l’interface API Gateway et l’API du serveur principal reposent sur des contrats différents : vous pouvez traduire un appel d’API REST en appel SOAP hérité ou dans un format personnalisé, puis transformer la réponse du serveur principal en une structure JSON claire pour le client. Elle ajoute de la complexité, mais offre le contrôle le plus étendu pour les intégrations avec des systèmes anciens.

L’intégration avec un service AWS connecte directement API Gateway aux services AWS, sans intermédiaire Lambda. Par exemple, vous pouvez configurer un point de terminaison POST qui écrit directement un message dans SQS, publie un message dans SNS ou démarre une exécution de Step Functions. Cela réduit la latence et élimine les coûts de fonction Lambda pour les opérations simples de routage. L’intégration nécessite de configurer un rôle IAM et des modèles de mappage pour formater correctement l’appel d’API AWS.

L’intégration Mock configure API Gateway pour renvoyer une réponse prédéfinie sans appeler de service principal. Vous définissez la réponse dans le modèle de mappage de la réponse d’intégration. Les intégrations Mock sont idéales pour : développer une API avant la création du service principal (les équipes frontend peuvent commencer immédiatement), tester unitairement les configurations d’API, renvoyer des en-têtes CORS standard ou fournir un substitut aux partenaires tiers pendant le développement. Les points de terminaison Mock peuvent également servir à bloquer les versions obsolètes d’une API en renvoyant le code 410 Gone.

CORS (Cross-Origin Resource Sharing) doit être activé lorsqu’un client de navigateur situé sur un domaine appelle votre API sur un autre domaine. HTTP API propose une configuration CORS en un clic ; REST API nécessite la création d’une méthode OPTIONS avec une intégration Mock qui renvoie les en-têtes CORS requis (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers). Une intégration proxy Lambda exige également que votre fonction Lambda renvoie les en-têtes CORS dans sa réponse.

REST API prend en charge la validation des requêtes : API Gateway peut vérifier que les paramètres de chaîne de requête, les en-têtes et le schéma du corps de la requête requis sont présents et correctement formatés, avant d’invoquer le service principal. Cela réduit les invocations Lambda inutiles dues aux requêtes mal formées et renvoie automatiquement des erreurs 400 standardisées. Définissez un modèle de requête à l’aide de JSON Schema et associez-le à la méthode pour activer la validation du corps. La validation des requêtes n’est pas disponible dans HTTP API.

API Gateway applique par défaut un délai d’expiration d’intégration de 29 secondes pour REST API et HTTP API (valeur maximale pour REST API, valeur fixe pour le proxy HTTP API). Si votre service principal met plus de 29 secondes à répondre, API Gateway renvoie une erreur 504 Gateway Timeout. Cela signifie que les fonctions Lambda invoquées de manière synchrone via API Gateway doivent s’exécuter en moins de 29 secondes, même si Lambda prend en charge des délais d’expiration allant jusqu’à 15 minutes. Pour les opérations longues, utilisez un modèle asynchrone : API Gateway déclenche Lambda, qui démarre une tâche asynchrone et renvoie immédiatement un ID de tâche.

Guide de choix des types d’intégration : Lambda Proxy : le plus courant et le plus simple, avec un contrôle complet de la requête dans Lambda ; Lambda Custom : lorsque vous avez besoin de transformer la requête ou la réponse dans la couche de la passerelle ; HTTP Proxy : pour les services principaux HTTP existants et les scénarios de migration ; HTTP Custom : pour traduire le format d’anciennes API ; AWS Service : pour éviter Lambda lors d’un routage simple vers SQS/SNS/DynamoDB ; Mock : pour les substituts de développement et les requêtes préliminaires CORS. Pour l’examen SAA-C03, les modèles Lambda Proxy et HTTP Proxy sont les plus fréquemment évalués.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’intégration Lambda Proxy transmet la requête complète à Lambda, qui contrôle la réponse — c’est l’intégration la plus simple et la plus courante ; que HTTP Proxy transmet les requêtes à des services principaux HTTP existants afin d’ajouter des fonctionnalités d’API Gateway sans modifier le service principal ; et que l’intégration Mock renvoie des réponses prédéfinies pour le développement et les tests frontend, sans infrastructure de service principal. Nous allons maintenant étudier l’autorisation d’API Gateway avec IAM, les autorisateurs Lambda et Cognito.