REST API versus HTTP API versus WebSocket API

HTTP API is ontworpen als een eenvoudiger, goedkoper en sneller alternatief voor REST API. De service ondersteunt alleen integraties met Lambda Proxy en HTTP Proxy—geen AWS-service-integraties en geen Mock. Belangrijke voordelen zijn: tot 70% lagere kosten dan REST API, lagere latentie, ingebouwde autorisatie met JWT's van OIDC en OAuth 2.0 (voor veel gebruikelijke authenticatiescenario's is geen Lambda-authorizer nodig) en automatische implementatie. Als je geen caching, gebruiksplannen of transformatie van verzoeken en antwoorden nodig hebt, is HTTP API de betere keuze.

WebSocket API houdt permanente, bidirectionele verbindingen tussen clients en de server in stand. In tegenstelling tot HTTP (verzoek-antwoord) maakt WebSocket het mogelijk dat de server op elk moment berichten naar clients pusht zonder dat de client hoeft te peilen. API Gateway beheert WebSocket-verbindingen en routeert berichten naar Lambda-functies op basis van route-expressies. Gebruik WebSocket API's voor realtime-applicaties, zoals chatapps, live dashboards, gezamenlijk bewerken, games en aandelenkoerstickers.

WebSocket API's hebben drie ingebouwde routes: $connect (wordt geactiveerd wanneer een client een verbinding opent), $disconnect (wordt geactiveerd wanneer een verbinding wordt gesloten) en $default (vangt niet-overeenkomende berichten op). Je kunt aangepaste routes toevoegen, zoals sendmessage, die aan specifieke Lambda-functies worden gekoppeld. Gebruik de beheer-API @connections om vanuit je Lambda-functie berichten terug te sturen naar verbonden clients met de verbindings-ID van de client.

De belangrijkste verschillen in één oogopslag:

• REST API: volledige functieset (caching, gebruiksplannen, transformaties, WAF), hogere kosten en ondersteuning voor alle integratietypen
• HTTP API: alleen Lambda- of HTTP-proxy, 70% goedkoper, ingebouwde JWT-authenticatie, lagere latentie en geen caching of gebruiksplannen
• WebSocket API: permanente bidirectionele verbindingen, ondersteuning voor pushberichten vanaf de server en kosten per miljoen berichten en per minuut verbindingstijd

Voor het SAA-C03-examen geldt: HTTP-vragen zonder realtime- of geavanceerde functies → HTTP API. Realtime pushberichten → WebSocket. Complexe API-functies → REST API.

API Gateway-API's worden geïmplementeerd in fasen (bijvoorbeeld dev, staging en prod). Elke fase heeft een eigen URL en instellingen voor snelheidsbeperking en kan verwijzen naar een specifieke momentopname van een implementatie. Gebruik fasevariabelen (vergelijkbaar met omgevingsvariabelen) om backend-eindpunten per fase te parametriseren. Laat bijvoorbeeld de fase dev naar een dev-Lambda-alias verwijzen en prod naar de prod-alias, zonder de API-configuratie te dupliceren.

API Gateway-URL's bevatten standaard de API-ID (bijvoorbeeld abc123.execute-api.us-east-1.amazonaws.com). Maak voor productiegebruik een aangepaste domeinnaam met een ACM-certificaat en koppel deze aan je API en fase. Gebruik toewijzingen van basispaden om meerdere API's onder één domein te hosten (bijvoorbeeld api.example.com/orders → Orders API en api.example.com/users → Users API). Voor aangepaste domeinnamen is een aliasrecord in Route 53 nodig dat naar het API Gateway-eindpunt verwijst.

REST API's kunnen in drie typen eindpunten worden geïmplementeerd: Edge-Optimised (CloudFront-frontend voor wereldwijde distributie, standaard), Regional (zonder CloudFront, lagere latentie voor clients in dezelfde regio of wanneer je je eigen CloudFront toevoegt) en Private (alleen toegankelijk vanuit je VPC via een VPC-interface-eindpunt, voor interne microservices). HTTP API's ondersteunen Edge-Optimised en Regional. WebSocket API's ondersteunen Regional en Private. Kies Regional voor API's die vanuit dezelfde regio worden gebruikt of wanneer je aangepaste CloudFront-distributies gebruikt.

API Gateway REST API's ondersteunen canary-implementaties op een fase. Je kunt een percentage van het verkeer naar een canary-implementatie (nieuwe versie) routeren, terwijl de rest naar de productie-implementatie gaat. Bewaak foutpercentages en latentie op de canary; als deze stabiel is, promoveer je hem naar 100%. Als er problemen ontstaan, draai je terug door het canary-aandeel op 0 in te stellen. Dit is vergelijkbaar met routering op basis van gewichten met Lambda-aliases en maakt veilige, geleidelijke API-updates mogelijk zonder te wisselen tussen blue/green-omgevingen.

Trefwoorden in SAA-C03-examenvragen waarmee je het API-type kunt bepalen: 'kosteneffectieve eenvoudige API' → HTTP API; 'realtime bidirectioneel', 'pushberichten vanaf de server' of 'chat' → WebSocket API; 'transformatie van verzoeken', 'gebruiksplannen', 'snelheidsbeperking met API-sleutels' of 'caching van antwoorden' → REST API. Wanneer de vraag eenvoudigweg gaat over 'Lambda als HTTP-eindpunt met lage kosten beschikbaar maken', is HTTP API de beste keuze. Wanneer de vraag complexe functies voor API-beheer of partners omvat, is REST API meestal het juiste antwoord.

In deze les heb je geleerd dat REST API de volledige functieset van API Gateway biedt (caching, transformaties, gebruiksplannen en WAF) tegen hogere kosten; dat HTTP API 70% goedkoper is, ingebouwde JWT-authenticatie en lagere latentie biedt en ideaal is voor Lambda- en HTTP-proxyscenario's zonder geavanceerde functies; en dat WebSocket API realtimecommunicatie met pushberichten vanaf de server mogelijk maakt via permanente verbindingen voor chat-, game- en livegegevensapplicaties. Hierna verkennen we API Gateway-integraties met Lambda, HTTP-backends en nagebootste antwoorden.