Développement d’API REST dans API Gateway - Amazon API Gateway

Développement d’API REST dans API Gateway

Dans Amazon API Gateway, vous créez une API REST sous la forme d’un ensemble d’entités programmables, appelées ressources. Par exemple, vous utilisez une ressource RestApi pour représenter une API qui peut contenir un ensemble d’entités de ressource.

Chaque entité Resource peut disposer d’une ou de plusieurs ressources Method. Une Method est une demande entrante soumise par le client, qui peut contenir les paramètres de demande suivants : un paramètre de chemin, un en-tête ou un paramètre de chaîne de requête. En outre, selon la méthode HTTP, la demande peut contenir un corps. Votre méthode définit la manière dont le client accède à la Resource exposée. Pour intégrer la Method avec un point de terminaison de backend, également appelé point de terminaison d’intégration, vous allez créer une ressource Integration. Cette opération transmet la demande entrante à un URI de point de terminaison d’intégration spécifié. Si nécessaire, vous pouvez transformer les paramètres ou le corps de la demande afin de répondre aux exigences du backend, ou vous pouvez créer une intégration de proxy, dans laquelle API Gateway envoie la demande complète dans un format normalisé à l’URI du point de terminaison d’intégration, puis envoie directement la réponse au client.

Pour les réponses, vous pouvez créer une ressource MethodResponse pour représenter la réponse reçue par le client, et créer une ressource IntegrationResponse pour représenter la réponse renvoyée par le backend. Utilisez une réponse d’intégration pour transformer les données de la réponse du backend avant de les renvoyer au client, ou pour transmettre la réponse du backend telle quelle au client.

Exemple de ressource pour une API REST

Le schéma suivant montre comment API Gateway implémente ce modèle de demande/réponse pour une intégration de proxy HTTP et sans proxy HTTP pour la ressource GET /pets. Le client envoie l’en-tête x-version:beta à API Gateway, qui envoie le code d’état 204 au client.

Dans une intégration sans proxy, API Gateway transforme les données pour répondre aux exigences du backend en modifiant la demande d’intégration et la réponse d’intégration. Dans une intégration sans proxy, vous accédez au corps dans la demande de méthode, mais vous le transformez dans la demande d’intégration. Lorsque le point de terminaison d’intégration renvoie une réponse avec un corps, vous y accédez et vous le transformez dans la réponse d’intégration. Vous ne pouvez pas modifier le corps dans la réponse de méthode.

Dans une intégration de proxy, le point de terminaison d’intégration modifie la demande et la réponse. API Gateway ne modifie ni la demande d’intégration ni la réponse d’intégration, et envoie la demande entrante au backend telle quelle.

Quel que soit le type d’intégration, le client envoie une demande à API Gateway, qui y répond de manière synchrone.

Non-proxy integration
Schéma d’une intégration sans proxy d’API Gateway
Proxy integration
Schéma d’une intégration de proxy API Gateway

Les exemples de journaux d’exécution suivants montrent ce qu’API Gateway enregistrerait dans l’exemple précédent. Pour plus de clarté, certaines valeurs et certains journaux initiaux ont été supprimés :

Non-proxy integration
Wed Feb 12 23:56:44 UTC 2025 : Starting execution for request: abcd-1234-5678 Wed Feb 12 23:56:44 UTC 2025 : HTTP Method: GET, Resource Path: /pets Wed Feb 12 23:56:44 UTC 2025 : Method request path: {} Wed Feb 12 23:56:44 UTC 2025 : Method request query string: {} Wed Feb 12 23:56:44 UTC 2025 : Method request headers: {x-version=beta} Wed Feb 12 23:56:44 UTC 2025 : Method request body before transformations: Wed Feb 12 23:56:44 UTC 2025 : Endpoint request URI: http://petstore-demo-endpoint.execute-api.com/petstore/pets Wed Feb 12 23:56:44 UTC 2025 : Endpoint request headers: {app-version=beta} Wed Feb 12 23:56:44 UTC 2025 : Endpoint request body after transformations: Wed Feb 12 23:56:44 UTC 2025 : Sending request to http://petstore-demo-endpoint.execute-api.com/petstore/pets Wed Feb 12 23:56:45 UTC 2025 : Received response. Status: 200, Integration latency: 123 ms Wed Feb 12 23:56:45 UTC 2025 : Endpoint response headers: {Date=Wed, 12 Feb 2025 23:56:45 GMT} Wed Feb 12 23:56:45 UTC 2025 : Endpoint response body before transformations: Wed Feb 12 23:56:45 UTC 2025 : Method response body after transformations: (null) Wed Feb 12 23:56:45 UTC 2025 : Method response headers: {X-Amzn-Trace-Id=Root=1-abcd-12345} Wed Feb 12 23:56:45 UTC 2025 : Successfully completed execution Wed Feb 12 23:56:45 UTC 2025 : Method completed with status: 204
Proxy integration
Wed Feb 12 23:59:42 UTC 2025 : Starting execution for request: abcd-1234-5678 Wed Feb 12 23:59:42 UTC 2025 : HTTP Method: GET, Resource Path: /pets Wed Feb 12 23:59:42 UTC 2025 : Method request path: {} Wed Feb 12 23:59:42 UTC 2025 : Method request query string: {} Wed Feb 12 23:59:42 UTC 2025 : Method request headers: {x-version=beta} Wed Feb 12 23:59:42 UTC 2025 : Method request body before transformations: Wed Feb 12 23:59:42 UTC 2025 : Endpoint request URI: http://petstore-demo-endpoint.execute-api.com/petstore/pets Wed Feb 12 23:59:42 UTC 2025 : Endpoint request headers: { x-version=beta} Wed Feb 12 23:59:42 UTC 2025 : Endpoint request body after transformations: Wed Feb 12 23:59:42 UTC 2025 : Sending request to http://petstore-demo-endpoint.execute-api.com/petstore/pets Wed Feb 12 23:59:43 UTC 2025 : Received response. Status: 204, Integration latency: 123 ms Wed Feb 12 23:59:43 UTC 2025 : Endpoint response headers: {Date=Wed, 12 Feb 2025 23:59:43 GMT} Wed Feb 12 23:59:43 UTC 2025 : Endpoint response body before transformations: Wed Feb 12 23:59:43 UTC 2025 : Method response body after transformations: Wed Feb 12 23:59:43 UTC 2025 : Method response headers: {Date=Wed, 12 Feb 2025 23:59:43 GMT} Wed Feb 12 23:59:43 UTC 2025 : Successfully completed execution Wed Feb 12 23:59:43 UTC 2025 : Method completed with status: 204

Pour importer une API similaire et la tester dans la AWS Management Console, consultez l’exemple d’API.

Autres fonctionnalités pour le développement des API REST

API Gateway prend en charge d’autres fonctionnalités pour le développement de votre API REST. Par exemple, pour aider vos clients à comprendre votre API, vous pouvez fournir une documentation sur l’API. Pour ce faire, ajoutez une ressource DocumentationPart pour une entité d’API prise en charge.

Pour contrôler la manière dont les clients appellent une API, utilisez des autorisations IAM, un mécanisme d’autorisation Lambda ou un groupe d’utilisateurs Amazon Cognito. Pour mesurer l’utilisation de votre API, configurez des plans d’utilisation pour limiter les demandes d’API. Vous pouvez les activer lors de la création ou de la mise à jour de l’API.

Le schéma suivant montre les fonctionnalités disponibles pour le développement d’API REST et indique où ces fonctionnalités sont configurées dans le modèle de demande/réponse.

Schéma des fonctionnalités d’API Gateway

Pour une introduction à la création d’une API, consultez Didacticiel : création d’une API REST avec une intégration de proxy Lambda. Pour en savoir plus sur les fonctionnalités d’API Gateway que vous pouvez utiliser lors du développement d’une API REST, consultez les rubriques suivantes. Ces rubriques contiennent des informations conceptuelles et des procédures que vous pouvez effectuer à l’aide de la console API Gateway, de l’API REST API Gateway, de l’AWS CLI ou de l’un des kits AWS SDK.