REST API jämfört med HTTP API och WebSocket API

Amazon API Gateway är en fullständigt hanterad tjänst som låter er skapa, publicera, skydda och övervaka API:er i valfri skala. Den fungerar som ingång för era backendtjänster—Lambda-funktioner, EC2-instanser, HTTP-backendservrar eller valfri AWS-tjänst. API Gateway hanterar trafikstyrning, auktorisering, throttling, övervakning och API-versionering, så att er backend kan fokusera på affärslogik i stället för API-infrastruktur.

REST API (den ursprungliga API Gateway-produkten) erbjuder den bredaste uppsättningen funktioner: transformering av begäran och svar med mappningsmallar, throttling per metod, användningsplaner med API-nycklar, cachelagring av svar, WAF-integration, X-Ray-spårning, resursprinciper och ömsesidig TLS med klientcertifikat. REST API:er stöder alla integrationstyper: Lambda, HTTP, AWS-tjänst, Mock och Lambda Proxy. Använd REST API när ni behöver avancerade funktioner som transformering, cachelagring eller användningsplaner.

HTTP API utformades som ett enklare, billigare och snabbare alternativ till REST API. Det stöder endast integrationerna Lambda proxy och HTTP proxy—inga AWS-tjänsteintegrationer och ingen mock-integration. Viktiga fördelar är upp till 70 % lägre kostnad än REST API, lägre latens, inbyggd JWT-auktorisering med OIDC och OAuth 2.0 (ingen Lambda-auktoriserare behövs i vanliga autentiseringsscenarier) samt automatisk distribution. Om ni inte behöver cachelagring, användningsplaner eller transformering av begäran och svar är HTTP API det bättre valet.

WebSocket API upprätthåller beständiga, dubbelriktade anslutningar mellan klienter och servern. Till skillnad från HTTP (begäran-svar) gör WebSocket att servern kan skicka meddelanden till anslutna klienter när som helst utan att klienten behöver polla. API Gateway hanterar WebSocket-anslutningar och routar meddelanden till Lambda-funktioner baserat på route-uttryck. Använd WebSocket-API:er för realtidsapplikationer: chattappar, liveinstrumentpaneler, samarbetsredigering, spel och aktiekurser i realtid.

WebSocket-API:er har tre inbyggda rutter: $connect (utlöses när en klient öppnar en anslutning), $disconnect (utlöses när en anslutning stängs) och $default (fångar meddelanden utan matchande route). Ni kan lägga till anpassade rutter som sendmessage och mappa dem till specifika Lambda-funktioner. Använd hanterings-API:t @connections för att skicka meddelanden tillbaka till anslutna klienter från er Lambda-funktion med hjälp av klientens anslutnings-ID.

Viktiga skillnader i korthet:

• REST API: alla funktioner (cachelagring, användningsplaner, transformeringar, WAF), högre kostnad och stöd för alla integrationstyper
• HTTP API: endast Lambda-/HTTP-proxy, 70 % billigare, inbyggd JWT-autentisering, lägre latens och ingen cachelagring eller användningsplaner
• WebSocket API: beständiga dubbelriktade anslutningar, stöd för push från servern och debitering per miljon meddelanden samt per minut anslutningstid

För SAA-C03-provet: HTTP-frågor utan realtid eller avancerade funktioner → HTTP API. Push i realtid → WebSocket. Komplexa API-funktioner → REST API.

API Gateway-API:er distribueras till stages (till exempel dev, staging och prod). Varje stage har sin egen URL och sina egna throttling-inställningar och kan referera till en specifik distributionsögonblicksbild. Använd stage-variabler (ungefär som miljövariabler) för att parameterisera backend-endpointar per stage—peka till exempel dev-stage till ett dev-Lambda-alias och prod till prod-aliaset utan att duplicera API-konfigurationen.

Som standard innehåller API Gateway-URL:er API-ID:t (till exempel abc123.execute-api.us-east-1.amazonaws.com). För produktionsanvändning skapar ni ett anpassat domännamn med stöd av ett ACM-certifikat och mappar det till ert API och er stage. Använd mappningar av basvägar för att hantera flera API:er under en domän (till exempel api.example.com/orders → Orders API och api.example.com/users → Users API). Anpassade domännamn kräver en Route 53-aliaspost som pekar på API Gateway-endpointen.

REST API:er kan distribueras med tre endpointtyper: Edge-Optimised (CloudFront som frontend för global distribution, standardalternativet), Regional (utan CloudFront, lägre latens för klienter i samma region eller när ni lägger till egen CloudFront) och Private (endast åtkomligt från ert VPC via en interface-VPC-endpoint, för interna mikrotjänster). HTTP API:er stöder Edge-Optimised och Regional. WebSocket API:er stöder Regional och Private. Välj Regional för API:er som används från samma region eller när ni använder egna CloudFront-distributioner.

API Gateway REST API:er stöder canary-distributioner på en stage. Ni kan routa en procentandel av trafiken till en canary-distribution (en ny version) medan resten går till produktionsdistributionen. Övervaka felfrekvens och latens för canary-versionen och befordra den till 100 % om den är stabil. Om problem uppstår återställer ni genom att sätta canary-vikten till 0. Detta motsvarar viktad routing med Lambda-alias och möjliggör säkra, gradvisa API-uppdateringar utan att växla mellan blue/green-miljöer.

Nyckelord i SAA-C03-frågor som hjälper er att identifiera API-typen: ”kostnadseffektivt enkelt API” → HTTP API; ”dubbelriktad kommunikation i realtid”, ”push från servern” eller ”chatt” → WebSocket API; ”transformering av begäran”, ”användningsplaner”, ”throttling av API-nycklar” eller ”cachelagring av svar” → REST API. När frågan helt enkelt gäller att exponera Lambda som en kostnadseffektiv HTTP-endpoint är HTTP API det bästa valet. När frågan omfattar komplexa funktioner för API-hantering eller partnerintegrationer är REST API vanligtvis rätt svar.

I den här lektionen har ni lärt er att REST API erbjuder hela API Gateways funktionsuppsättning (cachelagring, transformeringar, användningsplaner och WAF) till en högre kostnad, att HTTP API är 70 % billigare med inbyggd JWT-autentisering och lägre latens och passar för Lambda-/HTTP-proxyscenarier utan avancerade funktioner, samt att WebSocket API möjliggör push från servern i realtid över beständiga anslutningar för chatt-, spel- och applikationer med livedata. Härnäst utforskar vi API Gateway-integrationer med Lambda, HTTP-backendservrar och mock-svar.