Concepts Amazon API Gateway

API Gateway est un service AWS qui prend en charge les opérations suivantes :

Collection de ressources et de méthodes HTTP qui sont intégrées avec les points de terminaison HTTP du backend, les fonctions Lambda ou d’autres services AWS. Vous pouvez déployer cette collection en une ou plusieurs étapes. En règle générale, les ressources API sont organisées dans une arborescence des ressources selon la logique de l’application. Chaque ressource API peut exposer une ou plusieurs méthodes d’API comportant des verbes HTTP uniques pris en charge par API Gateway. Pour plus d’informations, consultez Choix entre les API HTTP et les API REST.

Collection de routes et de méthodes qui sont intégrées avec les points de terminaison HTTP du backend ou les fonctions Lambda. Vous pouvez déployer cette collection en une ou plusieurs étapes. Chaque route peut exposer une ou plusieurs méthodes d’API comportant des verbes HTTP uniques pris en charge par API Gateway. Pour plus d’informations, consultez Choix entre les API HTTP et les API REST.

Collection de routes et de clés de routage WebSocket qui sont intégrées avec les points de terminaison HTTP du backend, les fonctions Lambda ou d’autres services AWS. Vous pouvez déployer cette collection en une ou plusieurs étapes. Les méthodes d’API sont invoquées via des connexions WebSocket frontales que vous pouvez associer à un nom de domaine personnalisé enregistré.

Instantané à un moment donné de votre API API Gateway. Pour que les clients puissent accéder au déploiement et l’utiliser, il doit être associé à une ou plusieurs étapes d’API.

Votre compte AWS qui possède un déploiement API Gateway (par exemple, un fournisseur de services qui prend également en charge l’accès par programmation).

Nom d’hôte d’une API dans API Gateway déployée dans une région spécifique. Le nom d’hôte se présente sous la forme {api-id}.execute-api.{region}.amazonaws.com. Les types de points de terminaison d’API suivants sont pris en charge :

Chaîne alphanumérique utilisée par API Gateway pour identifier un développeur d’appli qui utilise votre API REST ou WebSocket. API Gateway peut générer des clés d’API pour vous, ou vous pouvez les importer à partir d’un fichier CSV. Vous pouvez utiliser des clés d’API avec des mécanismes d’autorisation Lambda ou des plans d’utilisation pour contrôler l’accès à vos API.

Consultez l’entrée Points de terminaison d’API.

Voir Développeur de l’API.

Référence logique à un état du cycle de vie de votre API (par exemple, « dev », « prod », « bêta », « v2 »). Les étapes d’API sont identifiées par l’ID de l’API et un nom d’étape.

Créateur d’applications qui peut disposer ou non d’un compte AWS et qui interagit avec l’API que vous, le développeur de l’API, avez déployée. Les développeurs d’applications sont vos clients. Un développeur d’applications est généralement identifié par une clé d’API.

Lorsqu’un nouveau client est connecté via une connexion WebSocket, vous pouvez appeler une intégration dans API Gateway pour stocker l’URL de rappel du client. Vous pouvez ensuite utiliser cette URL de rappel pour envoyer des messages au client à partir du système backend.

Application qui permet à vos clients d’enregistrer, de découvrir et de s’abonner à vos produits API (plans d’utilisation API Gateway), de gérer leurs clés d’API et de consulter leurs métriques d’utilisation de vos API.

Le nom d’hôte par défaut d’une API API Gateway déployée dans la région spécifiée tout en utilisant une distribution CloudFront visant à faciliter l’accès client généralement à partir des régions AWS. Les demandes d’API sont acheminées vers le point de présence CloudFront le plus proche, ce qui améliore généralement le temps de connexion des clients dispersés géographiquement.

Consultez l’entrée Points de terminaison d’API.

Interface interne d’une route d’API WebSocket ou d’une méthode d’API REST dans API Gateway, dans laquelle vous mappez le corps d’une demande de routage ou les paramètres et le corps d’une demande de méthode dans les formats requis par le backend.

Interface interne d’une route d’API WebSocket ou d’une méthode d’API REST dans API Gateway, dans laquelle vous mappez les codes de statut, les en-têtes et la charge utile reçus du backend au format de réponse qui est renvoyé à une application cliente.

Script en langage VTL (Velocity Template Language), permettant de convertir le corps d’une demande du format de données frontend au format de données backend, ou de convertir le corps d’une réponse du format de données backend au format de données frontend. Les modèles de mappage peuvent être spécifiés dans la demande ou la réponse d’intégration. Ils peuvent faire référence aux données rendues accessibles au moment de l’exécution en tant que variables de contexte et d’étape.

Le mappage peut être aussi simple qu’une transformation d’identité qui transmet tels quels les en-têtes ou le corps via l’intégration depuis le client vers le serveur principal pour une demande. Cela s’applique également à une réponse, la charge utile étant transmise du serveur principal au client.

Interface publique d’une méthode d’API dans API Gateway qui définit les paramètres et le corps qu’un développeur d’application doit envoyer dans des demandes pour accéder au backend via l’API.

Interface publique d’une API REST qui définit les codes de statut, les en-têtes et les modèles de corps qu’un développeur d’application doit attendre des réponses de l’API.

Dans une intégration simulée, des réponses d’API sont générées directement depuis API Gateway, sans recourir à un backend d’intégration. En tant que développeur d’API, vous décidez de la façon dont API Gateway répond à une demande d’intégration simulée. 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 de statut donné.

Schéma de données spécifiant la structure de données de la charge utile d’une demande ou d’une réponse. Un modèle est nécessaire pour générer un kit SDK fortement typé d’une API. Il est également utilisé pour valider des charges utiles. Un modèle est pratique pour générer un exemple de modèle de mappage afin d’initier la création d’un modèle de mappage de production. Bien qu’utile, un modèle n’est pas obligatoire pour créer un modèle de mappage.

Consultez l’entrée Point de terminaison de l’API privée.

Point de terminaison d’API qui est exposé via des points de terminaison de VPC d’interface et qui permet à un client d’accéder en toute sécurité aux ressources de l’API privée à l’intérieur d’un VPC. Les API privées sont isolées de l’Internet public et il n’est possible d’y accéder qu’à l’aide de points de terminaison d’un VPC pour API Gateway auxquels un accès a été accordé.

Type d’intégration API Gateway permettant à un client d’accéder à des ressources dans le VPC d’un client via un point de terminaison d’API REST privé sans exposer les ressources à l’Internet public.

Configuration d’intégration API Gateway simplifiée. Vous pouvez configurer une intégration de proxy en tant qu’intégration de proxy HTTP ou intégration de proxy Lambda.

Pour l’intégration de proxy HTTP, API Gateway transfère l’intégralité de la demande et de la réponse entre le serveur frontal et un backend HTTP. Pour l’intégration de proxy Lambda, API Gateway envoie l’intégralité de la demande sous forme d’entrée à une fonction Lambda du backend. Ensuite, API Gateway transforme la sortie de la fonction Lambda en une réponse HTTP du serveur frontal.

Dans les API REST, l’intégration de proxy est plus couramment utilisée avec une ressource proxy, qui est représentée par une variable de chemin gourmande (par exemple, {proxy+}) combinée à la méthode ANY fourre-tout.

Vous pouvez utiliser la fonction de création rapide pour simplifier la création d’une API HTTP. La création rapide crée une API avec une intégration Lambda ou HTTP, une route fourre-tout par défaut et une étape par défaut configurée pour déployer automatiquement les modifications. Pour plus d’informations, consultez Création d’une API HTTP à l’aide de la CLI AWS.

Nom d’hôte d’une API qui est déployée dans la région spécifiée afin de servir des clients (ex. : instances EC2) situés dans la même région AWS. Les demandes d’API ciblent directement l’API API Gateway spécifique à la région, sans passer par une distribution CloudFront. Dans le cas de demandes internes à une région, le point de terminaison régional évite l’aller-retour inutile avec une distribution CloudFront.

De plus, vous pouvez appliquer le routage basé sur la latence aux points de terminaison régionaux afin de déployer une API dans plusieurs régions à l’aide de la même configuration de point de terminaison d’API régionale. Pour ce faire, définissez le même nom de domaine personnalisé pour chaque API déployée et configurez des enregistrements DNS basés sur la latence dans Route 53 afin d’acheminer les demandes des clients vers la région ayant la plus faible latence.

Consultez l’entrée Points de terminaison d’API.

Une route WebSocket dans API Gateway est utilisée pour diriger les messages entrants vers une intégration spécifique, telle qu’une fonction AWS Lambda, sur la base du contenu du message. Lorsque vous définissez votre API WebSocket, vous spécifiez une clé de routage et un serveur principal d’intégration. La clé de routage est un attribut du corps du message. Lorsque la clé de routage est mise en correspondance dans un message entrant, le serveur principal d’intégration est invoqué.

Une route par défaut peut également être définie pour des clés de routage qui ne correspondent pas ou pour spécifier un modèle de proxy qui transmet le message tel quel à des composants du serveur principal qui effectuent le routage et traitent la demande.

Interface publique d’une méthode d’API WebSocket dans API Gateway qui définit le corps qu’un développeur d’application doit envoyer dans les demandes pour accéder au backend via l’API.

Interface publique d’une API WebSocket qui définit les codes de statut, les en-têtes et les modèles de corps qu’un développeur d’application doit attendre d’API Gateway.

Un plan d’utilisation donne aux clients d’API sélectionnés l’accès à une ou plusieurs API REST ou WebSocket déployées. Vous pouvez utiliser un plan d’utilisation pour configurer des limitations et des quotas, qui sont appliquées individuellement à chaque clé d’API client.

API Gateway maintient une connexion persistante entre les clients et API Gateway lui-même. Il n’y a pas de connexion persistante entre API Gateway et les intégrations backend telles que les fonctions Lambda. Les services backend sont appelés selon les besoins, en fonction du contenu des messages reçus des clients.