Begriff
API Gateway
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir ein riesiges Hotel vor (deine Software). Es gibt Köche, Putzkräfte, Elektriker (Microservices). Gäste (Nutzer) sollen aber nicht direkt in die Küche rennen, um Essen zu bestellen. Sie gehen zur Rezeption. Die Rezeption ist das API Gateway.
- Sie nimmt alle Wünsche entgegen.
- Sie prüft: "Sind Sie Gast hier?" (Sicherheit).
- Sie leitet den Wunsch an die richtige Abteilung weiter ("Küche, einmal Pizza für Zimmer 101").
Es ist der zentrale Eingang für alle Anfragen von außen.
Merksatz: Eine zentrale Komponente, die als "Haustür" für alle API-Anfragen dient und Aufgaben wie Sicherheit und Weiterleitung übernimmt.
Wenn du eine App baust, willst du nicht, dass die App 50 verschiedene Server-Adressen kennen muss (auth-server.com, user-server.com, payment-server.com).
Die App kennt nur eine Adresse: api.meine-app.com.
Das Gateway dahinter sortiert:
/login-> geht zum Auth-Service./pay-> geht zum Payment-Service.
Marktführer: Kong, AWS API Gateway, Apigee (Google).
1. Rate Limiting (Drosselung)
Schutz vor Angriffen: "Maximal 100 Anfragen pro Sekunde pro User." Das Gateway zählt mit. Kommt Anfrage Nr. 101, blockt es sofort ("429 Too Many Requests"). Die sensiblen Server dahinter merken davon nichts und werden nicht überlastet.
2. Authentication Offloading
Statt dass jeder Microservice selbst Passwörter prüft (redundant und unsicher), macht das Gateway das einmal am Eingang. Es prüft das Token, und wenn es gültig ist, sagt es den Services: "Das ist User 123, vertraut mir."
1. API Gateway vs. Service Mesh (Envoy/Istio)
Ein Gateway ist für den Nord-Süd-Traffic (Internet zu internen Services) gedacht. Wenn Microservice A (Shopping Cart) mit Microservice B (Payment) reden will, ist das Ost-West-Traffic. Theoretisch könnten sie das Gateway dafür nutzen, aber das wäre langsam (ein Extra-Hop) und würde das Gateway zum gigantischen Flaschenhals machen. Hierfür nutzt man heute ein Service Mesh (oft über Sidecar-Proxy wie Envoy), das die direkte Kommunikation der internen Microservices absichert (mTLS) und steuert, ohne den Gateway-Umweg.
2. Payload Transformation und Versionierung
Ein gutes Gateway ist ein Dolmetscher.
Die native Backend-API antwortet vielleicht mit einem alten XML-Format (weil das System 20 Jahre alt ist).
Das Gateway kann so konfiguriert werden, dass es dieses XML "on the fly" in modernes JSON (JavaScript Object Notation) umschreibt, bevor es das Paket an die Mobile-App des Kunden schickt.
Außerdem ermöglicht das Gateway einfache API-Versionierung (Header-Routing): "Wenn im HTTP-Header v=2 mitgesendet wird, leite an den neuen Kubernetes-Cluster weiter, sonst an die alten Server".
3. Circuit Breaker Pattern
Wenn der dahinterliegende Payment-Service abgestürzt ist, versuchen oft tausende API-Calls weiter sekündlich, ihn zu erreichen, rennen in Timeouts und fressen alle Verbindungs-Ressourcen des Gateways auf (Cascading Failure). Das API Gateway implementiert einen Circuit Breaker (Sicherungsschalter). Fällt der Service dreimal aus, "fliegt die Sicherung". Das Gateway blockt alle weiteren Anfragen sofort lokal mit 503 Service Unavailable, ohne den kaputten Server überhaupt noch anzufunken, bis dieser nach einer Abkühlphase (z.B. 1 Minute) wieder "gesund" meldet ("Half-Open" State).
Quick-Check
Ist das nicht ein "Single Point of Failure"?
Ja! Wenn die Rezeption brennt, kommt niemand mehr ins Hotel. Deshalb betreibt man Gateways oft im Cluster (mehrere Rezeptionisten).Was ist der Unterschied zum Load Balancer?
Ein Load Balancer verteilt Last innerhalb einer Gruppe gleicher Server (Webserver 1, 2, 3). Ein API Gateway verteilt Anfragen basierend auf Inhalt an verschiedene Services (/users, /billing) und macht dazu noch Logik wie Auth.Muss ich das selbst programmieren?
Bloß nicht. Nimm fertige Lösungen (Kong, Traefik, Nginx). Die sind millionenfach getestet und sicher.