Concepts API d'Amazon Gateway

La section suivante décrit les concepts d'introduction à l'utilisation de API Gateway.

Passerelle API

APIGateway est un AWS service qui prend en charge les éléments suivants :

• Création, déploiement et gestion d'une interface de programmation d'RESTfulapplications (API) pour exposer les HTTP points de terminaison, les AWS Lambda fonctions ou d'autres AWS services du backend.

• Création, déploiement et gestion d'un WebSocketAPIpour exposer des AWS Lambda fonctions ou d'autres AWS services.

• Invocation de API méthodes exposées via le frontend HTTP et WebSocket les points de terminaison.

APIPasserelle REST API

Ensemble de HTTP ressources et de méthodes intégrées aux HTTP points de terminaison du backend, aux fonctions Lambda ou à d'autres services. AWS Vous pouvez déployer cette collection en une ou plusieurs étapes. Généralement, les API ressources sont organisées dans une arborescence de ressources conformément à la logique de l'application. Chaque API ressource peut exposer une ou plusieurs API méthodes dotées de HTTP verbes uniques pris en charge par API Gateway. Pour plus d’informations, consultez Choisissez entre REST APIs et HTTP APIs.

APIPasserelle HTTP API

Ensemble de routes et de méthodes intégrées aux HTTP points de terminaison du backend ou aux fonctions Lambda. Vous pouvez déployer cette collection en une ou plusieurs étapes. Chaque itinéraire peut exposer une ou plusieurs API méthodes dotées de HTTP verbes uniques pris en charge par API Gateway. Pour plus d’informations, consultez Choisissez entre REST APIs et HTTP APIs.

APIPasserelle WebSocket API

Ensemble de WebSocket routes et de clés de route intégrées aux HTTP points de terminaison du backend, aux fonctions Lambda ou à d'autres services. AWS Vous pouvez déployer cette collection en une ou plusieurs étapes. APIles méthodes sont invoquées via des WebSocket connexions frontales que vous pouvez associer à un nom de domaine personnalisé enregistré.

Déploiement API

Un point-in-time aperçu de votre API passerelleAPI. Pour être disponible pour les clients, le déploiement doit être associé à une ou plusieurs API étapes.

Développeur API

Votre AWS compte propriétaire d'un déploiement de API Gateway (par exemple, un fournisseur de services qui prend également en charge l'accès programmatique).

Point de terminaison API

Nom d'hôte pour une API passerelle intégrée déployée API 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 API points de terminaison suivants sont pris en charge :

• Point de terminaison optimisé pour les périphériques API

• APIPoint de terminaison privé

• APIPoint de terminaison régional

Clé API

Chaîne alphanumérique utilisée par API Gateway pour identifier un développeur d'applications qui utilise votre REST ou WebSocket API. APIGateway peut générer des API clés en votre nom ou vous pouvez les importer à partir d'un CSV fichier. Vous pouvez utiliser des API clés conjointement avec des autorisateurs Lambda ou des plans d'utilisation pour contrôler l'accès à votre. APIs

Voir les APIpoints de terminaison.

APIpropriétaire

Voir APIdéveloppeur.

APIscène

Une référence logique à l'état de votre cycle de vie API (par exemple, « dev », « prod », « beta », « v2 »). APIles étapes sont identifiées par un API identifiant et un nom de scène.

Développeur d'applications

Un créateur d'application qui possède ou non un AWS compte et qui interagit avec l'application API que vous, le API développeur, avez déployée. Les développeurs d'applications sont vos clients. Un développeur d'applications est généralement identifié par une APIclé.

Rappel URL

Lorsqu'un nouveau client est connecté via une WebSocket connexion, vous pouvez appeler une intégration dans API Gateway pour enregistrer le rappel URL du client. Vous pouvez ensuite utiliser ce rappel URL pour envoyer des messages au client depuis le système principal.

Portail des développeurs

Une application qui permet à vos clients de s'inscrire, de découvrir et de s'abonner à vos API produits (plans d'utilisation de API Gateway), de gérer leurs API clés et de consulter leurs statistiques d'utilisation pour vousAPIs.

Point de terminaison optimisé pour les périphériques API

Le nom d'hôte par défaut d'une API passerelle API déployée dans la région spécifiée tout en utilisant une CloudFront distribution pour faciliter l'accès des clients, généralement depuis plusieurs AWS régions. APIles demandes sont acheminées vers le CloudFront point de présence (POP) le plus proche, ce qui améliore généralement le temps de connexion pour les clients géographiquement divers.

Voir les APIpoints de terminaison.

Demande d'intégration

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

Réponse d'intégration

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

Modèle de mappage

Script en langage Velocity Template (VTL) qui transforme le corps d'une demande du format de données frontal au format de données principal, ou qui transforme un corps de réponse du format de données principal au format de données frontal. 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 API méthode dans API Gateway qui définit les paramètres et le corps qu'un développeur d'applications doit envoyer dans les demandes pour accéder au backend via leAPI.

Réponse de méthode

Interface publique d'un REST API qui définit les codes de statut, les en-têtes et les modèles corporels auxquels un développeur d'applications doit s'attendre dans les réponses duAPI.

Intégration fictive

Dans une intégration fictive, API les réponses sont générées directement à partir de API Gateway, sans avoir besoin d'un backend d'intégration. En tant que API développeur, 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 requis pour générer un caractère fortement typé SDK deAPI. 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.

Privé API

Voir Point de APIterminaison privé.

APIPoint de terminaison privé

Un API point de terminaison exposé via les VPC points de terminaison d'interface et permettant à un client d'accéder en toute sécurité à API des ressources privées au sein d'unVPC. APIsLes réseaux privés sont isolés de l'Internet public et ne sont accessibles qu'à l'aide des VPC points de terminaison de API Gateway auxquels l'accès a été accordé.

Intégration privée

Type d'intégration de API passerelle permettant à un client d'accéder aux ressources d'un client VPC via un point de REST API terminaison privé sans exposer les ressources à l'Internet public.

Intégration de proxy

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

Pour l'intégration du HTTP proxy, API Gateway transmet l'intégralité de la demande et de la réponse entre le frontend et un HTTP backend. Pour l'intégration du proxy Lambda, API Gateway envoie l'intégralité de la demande en entrée à une fonction Lambda principale. APIGateway transforme ensuite la sortie de la fonction Lambda en réponse frontaleHTTP.

Dans RESTAPIs, l'intégration par proxy est le plus souvent utilisée avec une ressource proxy, qui est représentée par une variable de chemin gourmande (par exemple,{proxy+}) combinée à une méthode fourre-toutANY.

Création rapide

Vous pouvez utiliser la création rapide pour simplifier la création d'un HTTPAPI. La création rapide crée une API solution avec un Lambda ou une HTTP intégration, 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 AWS CLI.

APIPoint de terminaison régional

Le nom d'hôte d'un API serveur déployé dans la région spécifiée et destiné à servir des clients, tels que EC2 des instances, dans la même AWS région. APIles demandes sont directement dirigées vers la API passerelle spécifique à la région API sans passer par aucune CloudFront distribution. Pour les demandes internes à la région, un point de terminaison régional évite les allers-retours inutiles vers une CloudFront distribution.

En outre, vous pouvez appliquer un routage basé sur la latence sur les points de terminaison régionaux pour déployer un API vers plusieurs régions en utilisant la même configuration de point de API terminaison régional, définir le même nom de domaine personnalisé pour chaque point déployé API et configurer des DNS enregistrements basés sur la latence dans Route 53 afin d'acheminer les demandes des clients vers la région présentant la latence la plus faible.

Voir les APIpoints de terminaison.

Acheminement

Dans API Gateway, un WebSocket itinéraire est utilisé pour diriger les messages entrants vers une intégration spécifique, telle qu'une AWS Lambda fonction, en fonction du contenu du message. Lorsque vous définissez votre WebSocket API, vous spécifiez une clé de route et un backend 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 WebSocket API méthode dans API Gateway qui définit le corps qu'un développeur d'applications doit envoyer dans les demandes pour accéder au backend via leAPI.

Réponse de routage

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

Plan d'utilisation

Un plan d'utilisation permet aux API clients sélectionnés d'accéder à un ou plusieurs ou plusieurs appareils REST ou WebSocket APIs. Vous pouvez utiliser un plan d'utilisation pour configurer les limites de limitation et de quota, qui sont appliquées aux clés client API individuelles.

WebSocket connexion

APIGateway maintient une connexion permanente entre les clients et API Gateway lui-même. Il n'existe aucune connexion permanente entre API Gateway et les intégrations principales telles que les fonctions Lambda. Les services backend sont appelés selon les besoins, en fonction du contenu des messages reçus des clients.