REST API vs. HTTP API vs. WebSocket API
Verstehen Sie die Abwägungen zwischen REST API (funktionsreich), HTTP API (geringe Latenz und Kosten) und WebSocket API (bidirektional) und wählen Sie passend aus.
REST API vs. HTTP API vs. WebSocket API ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Warum API Gateway existiert
Amazon API Gateway ist ein vollständig verwalteter Service, mit dem Sie APIs jeder Größenordnung erstellen, veröffentlichen, absichern und überwachen können. Es dient als zentraler Einstiegspunkt für Ihre Backend-Services – Lambda-Funktionen, EC2-Instances, HTTP-Backends oder beliebige AWS-Services. API Gateway übernimmt Verkehrsverwaltung, Autorisierung, Drosselung, Überwachung und API-Versionierung, sodass sich Ihr Backend auf die Geschäftslogik statt auf Aspekte der API-Infrastruktur konzentrieren kann.
REST API: Funktionsreiche klassische API
REST API (das ursprüngliche API-Gateway-Produkt) bietet den größten Funktionsumfang: Anfrage-/Antworttransformation mit Mapping-Vorlagen, Drosselung pro Methode, Nutzungspläne mit API-Schlüsseln, Antwort-Caching, WAF-Integration, X-Ray-Tracing, Ressourcenrichtlinien und gegenseitiges TLS mit Clientzertifikaten. REST APIs unterstützen alle Integrationstypen: Lambda, HTTP, AWS-Service, Mock und Lambda Proxy. Verwenden Sie REST API, wenn Sie erweiterte Funktionen wie Transformation, Caching oder Nutzungspläne benötigen.
HTTP API: Kostengünstige Alternative mit niedriger Latenz
HTTP API wurde als einfachere, günstigere und schnellere Alternative zu REST API entwickelt. Es unterstützt ausschließlich Lambda-Proxy- und HTTP-Proxy-Integrationen – keine AWS-Service-Integrationen und keine Mock-Integrationen. Die wichtigsten Vorteile: bis zu 70 % niedrigere Kosten als bei REST API, geringere Latenz, integrierte native OIDC- und OAuth-2.0-JWT-Autorisierung (für gängige Authentifizierungsszenarien ist kein Lambda-Autorisierer erforderlich) sowie automatische Bereitstellung. Wenn Sie kein Caching, keine Nutzungspläne und keine Anfrage-/Antworttransformation benötigen, ist HTTP API die bessere Wahl.
# Create a simple HTTP API
aws apigatewayv2 create-api \
--name 'MyHttpAPI' \
--protocol-type HTTP \
--target 'arn:aws:lambda:us-east-1:123456789012:function:MyLambda'WebSocket API: Bidirektionale Echtzeitkommunikation
WebSocket API hält dauerhafte, bidirektionale Verbindungen zwischen Clients und dem Server aufrecht. Im Gegensatz zu HTTP (Anfrage-Antwort) ermöglicht WebSocket dem Server, jederzeit Nachrichten an verbundene Clients zu senden, ohne dass der Client regelmäßig Anfragen stellen muss. API Gateway verwaltet WebSocket-Verbindungen und leitet Nachrichten anhand von Routen-Ausdrücken an Lambda-Funktionen weiter. Verwenden Sie WebSocket APIs für Echtzeitanwendungen wie Chat-Apps, Live-Dashboards, kollaboratives Bearbeiten, Spiele und Börsenticker.
WebSocket-Routen und Verbindungsverwaltung
WebSocket APIs verfügen über drei integrierte Routen: $connect (wird ausgelöst, wenn ein Client eine Verbindung öffnet), $disconnect (wird ausgelöst, wenn eine Verbindung geschlossen wird) und $default (fängt nicht übereinstimmende Nachrichten ab). Sie können benutzerdefinierte Routen wie sendmessage hinzufügen und bestimmten Lambda-Funktionen zuordnen. Verwenden Sie die Verwaltungs-API @connections, um aus Ihrer Lambda-Funktion mithilfe der Verbindungs-ID Nachrichten an verbundene Clients zu senden.
# Send a message to a specific WebSocket client from Lambda
import boto3
gw_client = boto3.client(
'apigatewaymanagementapi',
endpoint_url='https://abc123.execute-api.us-east-1.amazonaws.com/prod'
)
def lambda_handler(event, context):
connection_id = event['requestContext']['connectionId']
gw_client.post_to_connection(
Data='{"type": "message", "text": "Hello!"}',
ConnectionId=connection_id
)Funktionsvergleich: REST vs. HTTP vs. WebSocket
Die wichtigsten Unterschiede im Überblick:
- REST API: vollständiger Funktionsumfang (Caching, Nutzungspläne, Transformationen, WAF), höhere Kosten, unterstützt alle Integrationstypen
- HTTP API: nur Lambda-/HTTP-Proxy, 70 % günstiger, integrierte JWT-Authentifizierung, geringere Latenz, kein Caching und keine Nutzungspläne
- WebSocket API: dauerhafte bidirektionale Verbindungen, unterstützt Server-Push, Abrechnung pro Million Nachrichten und pro Minute Verbindungszeit
Für die SAA-C03-Prüfung gilt: HTTP-Fragen ohne Echtzeit- oder erweiterte Funktionen → HTTP API. Echtzeit-Push → WebSocket. Komplexe API-Funktionen → REST API.
Stages und Bereitstellungen
API-Gateway-APIs werden in Stages bereitgestellt (z. B. dev, staging, prod). Jede Stage verfügt über eine eigene URL und eigene Drosselungseinstellungen und kann auf einen bestimmten Bereitstellungs-Snapshot verweisen. Verwenden Sie Stage-Variablen (ähnlich wie Umgebungsvariablen), um Backend-Endpunkte je Stage zu parametrisieren – beispielsweise, indem Sie die Stage dev auf einen Dev-Lambda-Alias und prod auf den Prod-Alias verweisen lassen, ohne die API-Konfiguration zu duplizieren.
# REST API: create a deployment and stage
aws apigateway create-deployment \
--rest-api-id 'abc123' \
--stage-name 'prod'
# Set stage variable
aws apigateway update-stage \
--rest-api-id 'abc123' \
--stage-name 'prod' \
--patch-operations 'op=replace,path=/variables/lambdaAlias,value=prod'Benutzerdefinierte Domainnamen und Basis-Pfad-Zuordnungen
API-Gateway-URLs enthalten standardmäßig die API-ID (z. B. abc123.execute-api.us-east-1.amazonaws.com). Erstellen Sie für den Produktionseinsatz einen benutzerdefinierten Domainnamen, der durch ein ACM-Zertifikat abgesichert ist, und ordnen Sie ihn Ihrer API und Stage zu. Verwenden Sie Basis-Pfad-Zuordnungen, um mehrere APIs unter einer Domain zu hosten (z. B. api.example.com/orders → Orders API, api.example.com/users → Users API). Für benutzerdefinierte Domainnamen ist ein Route-53-Aliasdatensatz erforderlich, der auf den API-Gateway-Endpunkt verweist.
Edge-optimierte, regionale und private APIs
REST APIs können mit drei Endpunkttypen bereitgestellt werden: Edge-optimiert (CloudFront-Frontend für globale Verteilung, Standard), regional (ohne CloudFront, geringere Latenz für Clients in derselben Region oder bei Verwendung eines eigenen CloudFront) und privat (nur innerhalb Ihrer VPC über einen VPC-Schnittstellenendpunkt erreichbar, für interne Microservices). HTTP APIs unterstützen Edge-optimiert und regional. WebSocket APIs unterstützen regional und privat. Wählen Sie „regional“ für APIs, die aus derselben Region verwendet werden, oder wenn Sie eigene CloudFront-Distributionen einsetzen.
Canary-Bereitstellungen mit API Gateway
API-Gateway-REST-APIs unterstützen Canary-Bereitstellungen auf einer Stage. Sie können einen Prozentsatz des Datenverkehrs an eine Canary-Bereitstellung (neue Version) weiterleiten, während der übrige Datenverkehr an die Produktionsbereitstellung geht. Überwachen Sie Fehlerquoten und Latenz der Canary-Bereitstellung. Wenn sie stabil ist, erhöhen Sie ihren Anteil auf 100 %. Bei Problemen können Sie einen Rollback durchführen, indem Sie das Canary-Gewicht auf 0 setzen. Dies entspricht dem gewichteten Routing von Lambda-Aliasen und ermöglicht sichere, schrittweise API-Aktualisierungen ohne den Wechsel zwischen Blue-Green-Umgebungen.
Den richtigen API-Typ für die Prüfung auswählen
Schlüsselbegriffe in SAA-C03-Prüfungsfragen zur Bestimmung des API-Typs: „kostengünstige einfache API“ → HTTP API; „bidirektional in Echtzeit“, „Server-Push“ oder „Chat“ → WebSocket API; „Anfragetransformation“, „Nutzungspläne“, „Drosselung per API-Schlüssel“, „Antwort-Caching“ → REST API. Wenn die Frage lediglich lautet, eine Lambda-Funktion kostengünstig als HTTP-Endpunkt bereitzustellen, ist HTTP API die richtige Wahl. Geht es um komplexe API-Verwaltungsfunktionen oder Partner, ist in der Regel REST API korrekt.
Schnelltest
Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: REST API bietet den vollständigen Funktionsumfang von API Gateway (Caching, Transformationen, Nutzungspläne, WAF) zu höheren Kosten; HTTP API ist 70 % günstiger, verfügt über integrierte JWT-Authentifizierung und eine geringere Latenz und eignet sich ideal für Lambda-/HTTP-Proxy-Szenarien ohne erweiterte Funktionen; und WebSocket API ermöglicht serverseitige Echtzeitkommunikation über dauerhafte Verbindungen für Chat-, Gaming- und Live-Datenanwendungen. Als Nächstes untersuchen wir API-Gateway-Integrationen mit Lambda, HTTP-Backends und Mock-Antworten.
Häufig gestellte Fragen
Ist die Lektion „REST API vs. HTTP API vs. WebSocket API“ kostenlos?
Ja — der vollständige Text von „REST API vs. HTTP API vs. WebSocket API“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „REST API vs. HTTP API vs. WebSocket API“?
Verstehen Sie die Abwägungen zwischen REST API (funktionsreich), HTTP API (geringe Latenz und Kosten) und WebSocket API (bidirektional) und wählen Sie passend aus. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?
Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „REST API vs. HTTP API vs. WebSocket API“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?
Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- REST API vs. HTTP API vs. WebSocket API
- Integrationen: Lambda, HTTP und Mock
- Autorisierung: IAM, Lambda Authorizers und Cognito
- Drosselung, Caching und Nutzungspläne