API REST ou API HTTP ou API WebSocket

Amazon API Gateway est un service entièrement géré qui vous permet de créer, publier, sécuriser et surveiller des API quelle que soit leur échelle. Il sert de point d’entrée à vos services principaux — fonctions Lambda, instances EC2, serveurs principaux HTTP ou tout autre service AWS. API Gateway gère la gestion du trafic, l’autorisation, la limitation du débit, la surveillance et le versionnage des API, afin que votre serveur principal puisse se concentrer sur la logique métier plutôt que sur les aspects liés à l’infrastructure des API.

API REST (produit API Gateway d’origine) offre l’ensemble de fonctionnalités le plus vaste : transformation des requêtes et des réponses avec des modèles de mappage, limitation du débit par méthode, plans d’utilisation avec clés d’API, mise en cache des réponses, intégration avec WAF, traçage X-Ray, politiques de ressources et TLS mutuel avec certificat client. Les API REST prennent en charge tous les types d’intégration : Lambda, HTTP, service AWS, simulée et proxy Lambda. Utilisez une API REST lorsque vous avez besoin de fonctionnalités avancées comme la transformation, la mise en cache ou les plans d’utilisation.

API HTTP a été conçue comme une solution alternative plus simple, moins coûteuse et plus rapide que l’API REST. Elle prend uniquement en charge les intégrations proxy Lambda et proxy HTTP — pas d’intégrations avec les services AWS ni d’intégration simulée. Ses principaux avantages sont un coût jusqu’à 70 % inférieur à celui d’une API REST, une latence réduite, une autorisation JWT native OIDC et OAuth 2.0 intégrée (aucun autorisateur Lambda n’est nécessaire pour les scénarios d’authentification courants) et le déploiement automatique. Si vous n’avez pas besoin de mise en cache, de plans d’utilisation ou de transformation des requêtes et des réponses, l’API HTTP constitue le meilleur choix.

API WebSocket maintient des connexions persistantes et bidirectionnelles entre les clients et le serveur. Contrairement à HTTP (requête-réponse), WebSocket permet au serveur d’envoyer des messages aux clients connectés à tout moment, sans que le client ait à interroger le serveur. API Gateway gère les connexions WebSocket et achemine les messages vers des fonctions Lambda en fonction d’expressions de routage. Utilisez les API WebSocket pour les applications en temps réel : applications de discussion, tableaux de bord en direct, édition collaborative, jeux et affichage des cours boursiers.

Les API WebSocket disposent de trois routes intégrées : $connect (déclenchée lorsqu’un client ouvre une connexion), $disconnect (déclenchée lorsqu’une connexion se ferme) et $default (capture les messages sans correspondance). Vous pouvez ajouter des routes personnalisées comme sendmessage, associées à des fonctions Lambda spécifiques. Utilisez l’API de gestion @connections pour renvoyer des messages aux clients connectés depuis votre fonction Lambda, en utilisant l’ID de connexion du client.

Principales différences en un coup d’œil :

• API REST : fonctionnalités complètes (mise en cache, plans d’utilisation, transformations, WAF), coût plus élevé et prise en charge de tous les types d’intégration
• API HTTP : proxy Lambda ou HTTP uniquement, 70 % moins chère, authentification JWT intégrée, latence réduite, sans mise en cache ni plans d’utilisation
• API WebSocket : connexions bidirectionnelles persistantes, possibilité d’envoyer des données depuis le serveur et facturation par million de messages et par minute de connexion

Pour l’examen SAA-C03 : questions HTTP sans temps réel ni fonctionnalités avancées → API HTTP. Envoi de données en temps réel depuis le serveur → WebSocket. Fonctionnalités d’API complexes → API REST.

Les API API Gateway sont déployées dans des étapes (par exemple, dev, staging et prod). Chaque étape possède sa propre URL et ses propres paramètres de limitation du débit, et peut faire référence à un instantané de déploiement spécifique. Utilisez les variables d’étape (semblables aux variables d’environnement) pour paramétrer les points de terminaison principaux selon l’étape — par exemple, faire pointer l’étape dev vers un alias Lambda de développement et prod vers l’alias de production, sans dupliquer la configuration de l’API.

Par défaut, les URL d’API Gateway contiennent l’ID de l’API (par exemple, abc123.execute-api.us-east-1.amazonaws.com). Pour une utilisation en production, créez un nom de domaine personnalisé associé à un certificat ACM et mappez-le vers votre API et votre étape. Utilisez les mappages de chemins de base pour héberger plusieurs API sous un même domaine (par exemple, api.example.com/orders → API Orders, api.example.com/users → API Users). Les noms de domaine personnalisés nécessitent un enregistrement d’alias Route 53 pointant vers le point de terminaison API Gateway.

Les API REST peuvent être déployées avec trois types de points de terminaison : optimisé pour le réseau périphérique (interface CloudFront pour une distribution mondiale, type par défaut), régional (sans CloudFront, avec une latence plus faible pour les clients de la même région ou lorsque vous ajoutez votre propre CloudFront) et privé (accessible uniquement depuis votre VPC via un point de terminaison VPC d’interface, pour les microservices internes). Les API HTTP prennent en charge les types optimisé pour le réseau périphérique et régional. Les API WebSocket prennent en charge les types régional et privé. Choisissez le type régional pour les API utilisées depuis la même région ou lorsque vous utilisez vos propres distributions CloudFront.

Les API REST API Gateway prennent en charge les déploiements canari au niveau d’une étape. Vous pouvez acheminer un pourcentage du trafic vers un déploiement canari (nouvelle version), tandis que le reste est dirigé vers le déploiement de production. Surveillez les taux d’erreur et la latence du canari ; s’il reste stable, faites-le passer à 100 %. En cas de problème, revenez en arrière en définissant le poids du canari sur 0. Cette approche est comparable au routage pondéré des alias Lambda et permet de mettre à jour les API progressivement et en toute sécurité, sans basculer entre des environnements bleu et vert.

Mots-clés des questions de l’examen SAA-C03 permettant d’identifier le type d’API : « API simple et économique » → API HTTP ; « bidirectionnelle en temps réel », « envoi de données depuis le serveur » ou « discussion » → API WebSocket ; « transformation des requêtes », « plans d’utilisation », « limitation du débit par clé d’API » ou « mise en cache des réponses » → API REST. Lorsque la question consiste simplement à « exposer Lambda comme point de terminaison HTTP à faible coût », l’API HTTP est le meilleur choix. Lorsque la question porte sur des fonctionnalités complexes de gestion des API ou sur des partenaires, l’API REST est généralement la bonne réponse.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’API REST fournit l’ensemble complet des fonctionnalités d’API Gateway (mise en cache, transformations, plans d’utilisation, WAF) à un coût plus élevé ; que l’API HTTP coûte 70 % moins cher, intègre l’authentification JWT et offre une latence réduite, ce qui la rend idéale pour les scénarios de proxy Lambda ou HTTP sans fonctionnalités avancées ; et que l’API WebSocket permet une communication en temps réel avec envoi de données depuis le serveur sur des connexions persistantes, notamment pour les discussions, les jeux et les applications de données en direct. Nous allons maintenant découvrir les intégrations d’API Gateway avec Lambda, les serveurs principaux HTTP et les réponses simulées.