Concepts Amazon API Gateway - Amazon API Gateway

Concepts Amazon API Gateway

API Gateway

API Gateway est un service AWS qui prend en charge les actions suivantes :

  • la création, le déploiement et la gestion d'une interface de programmation d'application (API) RESTful pour exposer les points de terminaison HTTP du back-end, les fonctions AWS Lambda ou d'autres services AWS.

  • la création, le déploiement et la gestion d'une API WebSocket pour exposer des fonctions AWS Lambda ou d'autres services AWS ;

  • l'invocation de méthodes d'API exposées via les points de terminaison HTTP et WebSocket frontaux.

API REST API Gateway

Collection de ressources et de méthodes qui sont intégrées aux points de terminaison HTTP du serveur principal, aux 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.

API Gateway HTTP API

Collection de routes et de méthodes qui sont intégrées aux points de terminaison HTTP back-end ou aux 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.

API WebSocket d'API Gateway

Collection de routes et de clés de route WebSocket qui sont intégrées aux points de terminaison HTTP du serveur principal, aux 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é.

Déploiement de l'API

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.

Développeur de l'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).

Point de terminaison d'API

Nom d'hôte pour 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 :

Clé API

Chaîne alphanumérique utilisée par API Gateway pour identifier un développeur d'application qui utilise votre API REST ou WebSocket. API Gateway peut générer des clés d'API en votre nom, 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.

Propriétaire de l'API

Voir Développeur de l'API.

Étape 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.

Développeur d'applications

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.

URL de rappel

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.

Portail des développeurs

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 API et de consulter leurs métriques d'utilisation de vos API.

Point de terminaison d'API optimisée pour les périphériques

Nom d'hôte par défaut d'une API API Gateway déployée dans la région spécifiée avec 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.

Demande d'intégration

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 serveur principal.

Réponse d'intégration

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 serveur principal au format de réponse qui est renvoyé à une application cliente.

Modèle de mappage

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.

Demande de méthode

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

Réponse de méthode

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.

Intégration fictive

Dans une intégration fictive, des réponses d'API sont générées directement depuis API Gateway, sans recourir à un serveur principal d'intégration. En tant que développeur d'API, vous décidez comment 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é.

Modèle

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.

API privée

Consultez l'entrée Point de terminaison de l'API privé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 sont uniquement accessibles à l'aide de points de terminaison de VPC pour API Gateway auxquels un accès a été accordé.

Intégration privée

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ée sans exposer les ressources à l'Internet public.

Intégration de proxy

Configuration d'intégration d'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 serveur principal HTTP. Pour l'intégration de proxy Lambda, API Gateway envoie l'intégralité de la demande en tant qu'entrée à une fonction Lambda du serveur principal. API Gateway transforme ensuite 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 de proxy, qui est représentée par une variable de chemin gourmande (par exemple, {proxy+}) combinée à la méthode ANY fourre-tout.

Création rapide

Vous pouvez utiliser la création rapide pour simplifier la création d'une HTTP API. 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 de plus amples informations, veuillez consulter Créer un HTTP API avec l'interface de ligne de commande AWS.

Point de terminaison d'API régional

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 requêtes d'API ciblent directement l'API API Gateway spécifique à la région, sans passer par une distribution CloudFront. Dans le cas de requêtes internes à une région, le point de terminaison régional évite l'aller-retour via une distribution CloudFront inutile.

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.

Route

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.

Demande de routage

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 serveur principal via l'API.

Réponse de routage

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.

Plan d'utilisation

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.

Connexion WebSocket

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 back-end telles que les fonctions Lambda. Les services back-end sont appelés selon les besoins, en fonction du contenu des messages reçus des clients.