Exécutez API Gateway localement avec AWS SAM - AWS Serverless Application Model

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exécutez API Gateway localement avec AWS SAM

L'exécution locale d'Amazon API Gateway peut présenter de nombreux avantages. Par exemple, l'exécution locale d'API Gateway vous permet de tester les points de terminaison d'API localement avant le déploiement AWS dans le cloud. Si vous effectuez d'abord des tests locaux, vous pouvez souvent réduire les tests et le développement dans le cloud, ce qui peut contribuer à réduire les coûts. De plus, l'exécution locale facilite le débogage.

Pour démarrer une instance locale d'API Gateway que vous pouvez utiliser pour tester la fonctionnalité de requête/réponse HTTP, utilisez la commande. sam local start-api AWS SAMCLI Cette fonctionnalité dispose d'un rechargement à chaud afin que vous puissiez rapidement développer et itérer vos fonctions.

Note

Le rechargement à chaud consiste à actualiser uniquement les fichiers qui ont été modifiés, l'état de l'application restant inchangé. En revanche, le rechargement en direct consiste à actualiser l'application entière et à perdre l'état de l'application.

Pour des instructions relatives à l'utilisation de la commande sam local start-api, veuillez consulter la section Présentation des tests avec sam local start-api.

Par défaut, AWS SAM utilise des intégrations de AWS Lambda proxy et prend en charge les deux HttpApi types de Api ressources. Pour plus d'informations sur les intégrations de proxy pour les types de HttpApi ressources, consultez la section Utilisation des intégrations de AWS Lambda proxy pour les API HTTP dans le guide du développeur d'API Gateway. Pour plus d'informations sur les intégrations de proxy avec les types de ressources Api, consultez Présentation de l'intégration de proxy Lambda API Gateway dans le Guide du développeur API Gateway.

Exemple :

$ sam local start-api

AWS SAM trouve automatiquement dans votre AWS SAM modèle toutes les fonctions dont les sources d'Apiévénements HttpApi ou les sources d'événements sont définies. Ensuite, il monte la fonction sur les chemins HTTP définis.

Dans l'exemple Api ci-dessous, la fonction Ratings monte ratings.py:handler() dans /ratings pour les demandes GET.

Ratings: Type: AWS::Serverless::Function Properties: Handler: ratings.handler Runtime: python3.9 Events: Api: Type: Api Properties: Path: /ratings Method: get

Voici un exemple de réponse Api :

// Example of a Proxy Integration response exports.handler = (event, context, callback) => { callback(null, { statusCode: 200, headers: { "x-custom-header" : "my custom header value" }, body: "hello world" }); }

Si vous modifiez le code de votre fonction, exécutez la commande sam build pour que sam local start-api détecte vos modifications.

Fichier de variable d'environnement

Pour déclarer localement des variables d'environnement qui remplacent les valeurs définies dans vos modèles, procédez comme suit :

  1. Créez un fichier JSON qui contient les variables d'environnement à remplacer.

  2. Utilisez l'argument --env-vars pour remplacer les valeurs définies dans vos modèles.

Déclaration des variables d'environnement

Pour déclarer des variables d'environnement qui s'appliquent globalement à toutes les ressources, spécifiez un objet Parameters comme suit :

{ "Parameters": { "TABLE_NAME": "localtable", "BUCKET_NAME": "testBucket", "STAGE": "dev" } }

Pour déclarer des variables d'environnement différentes pour chaque ressource, spécifiez des objets pour chaque ressource comme suit :

{ "MyFunction1": { "TABLE_NAME": "localtable", "BUCKET_NAME": "testBucket", }, "MyFunction2": { "TABLE_NAME": "localtable", "STAGE": "dev" } }

Lorsque vous spécifiez des objets pour chaque ressource, vous pouvez utiliser les identifiants suivants, énumérés dans l'ordre de la plus haute à la plus basse priorité :

  1. logical_id

  2. function_id

  3. function_name

  4. Identifiant de chemin complet

Vous pouvez utiliser les deux méthodes précédentes de déclaration des variables d'environnement dans un seul fichier. Ce faisant, les variables d'environnement que vous avez fournies pour des ressources spécifiques ont la priorité sur les variables d'environnement globales.

Enregistrez vos variables d'environnement dans un fichier JSON, tel que env.json.

Remplacement des valeurs des variables d'environnement

Pour remplacer les variables d'environnement par celles définies dans votre fichier JSON, utilisez l'argument --env-vars avec les commandes invoke ou start-api. Par exemple :

$ sam local start-api --env-vars env.json

Couches

Si votre application comporte des couches, pour plus d'informations sur la façon de déboguer les problèmes liés aux couches sur votre hôte local, consultez Améliorez l'efficacité en utilisant les couches Lambda avec AWS SAM.