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.
Après avoir créé votre API, vous devez la déployer pour que vos utilisateurs puissent l’appeler.
Pour déployer une API, vous devez créer un déploiement d’API et l’associer à une étape. Une étape est une référence logique à un état du cycle de vie de votre API (par exemple, dev
, prod
, beta
, v2
). Les étapes d’API sont identifiées par l’ID de l’API et un nom d’étape. Elles sont incluses dans l’URL que vous utilisez pour appeler l’API. Chaque étape est une référence nommée à un déploiement de l'API et elle est mise à la disposition des applications clientes à appeler.
Important
Chaque fois que vous mettez à jour une API, vous devez redéployer l’API vers une étape existante ou vers une nouvelle étape. La mise à jour d’une API inclut la modification des routes, des méthodes, des intégrations, des mécanismes d’autorisation, des ressources de politiques et de tout élément autre que les paramètres d’étape.
À mesure que votre API évolue, vous pouvez continuer à la déployer dans différentes étapes sous forme de versions distinctes de l’API. Vous pouvez également déployer vos mises à jour d’API en tant que déploiement de version Canary. Cela permet à vos clients API d’accéder, au cours de la même étape, à la version de production via la version de production, et à la version mise à jour via la version Canary.
Pour appeler une API déployée, le client soumet une demande par rapport à l’URL d’une API. L'URL est déterminée par le protocole d'une API (HTTP (S) ou (WSS)), le nom d'hôte, le nom de stage et le chemin de ressource (pour REST APIs). Le nom d’hôte et le nom de l’étape déterminent l’URL de base de l’API.
Avec le nom de domaine par défaut de l’API, l’URL de base (par exemple) d’une API REST à une étape donnée (
) a le format suivant :{stageName}
https://
{restapi-id}
.execute-api.{region}
.amazonaws.com/{stageName}
Pour rendre une URL de base par défaut de l’API plus conviviale, vous pouvez créer un nom de domaine personnalisé (par exemple, api.example.com
) pour remplacer le nom d’hôte par défaut de l’API. Pour prendre en charge plusieurs APIs sous le nom de domaine personnalisé, vous devez mapper une étape d'API à un chemin de base.
Avec un nom de domaine personnalisé
et l’étape d’API mappée à un chemin de base ({api.example.com}
) sous le nom de domaine personnalisé, l’URL de base d’une API REST est remplacée par : {basePath}
https://
{api.example.com}
/{basePath}
Pour chaque étape, vous pouvez optimiser les performances de l’API en ajustant les limitations de demande au niveau du compte par défaut et en activant la mise en cache des API. Vous pouvez également activer la journalisation des appels d'API vers CloudTrail ou CloudWatch, et sélectionner un certificat client pour le backend afin d'authentifier les demandes d'API. En outre, vous pouvez remplacer des paramètres au niveau d’une étape pour des méthodes individuelles et définir des variables d’étape pour transmettre à l’intégration d’API des contextes d’environnement spécifiques à l’étape au moment de l’exécution.
Les étapes permettent un contrôle de version solide de votre API. Par exemple, vous pouvez déployer une API dans une étape test
et une étape prod
, puis utiliser l’étape test
comme version de test et l’étape prod
comme version stable. Une fois que les mises à jour passent le test, vous pouvez migrer l’étape test
vers l’étape prod
. Pour ce faire, redéployez l’API dans l’étape prod
ou mettez à jour une valeur de variable d’étape en remplaçant le nom d’étape test
par prod
.
Dans cette section, nous expliquons comment déployer une API en utilisant la console API Gateway