Seit Lektion 4.12.1 hat die Kladde zwei Anwendungen, und mit jedem weiteren Dienst würde der Browser eine Adresse mehr kennen müssen. Jede davon bräuchte eigenes TLS-Material, eigene Regeln für Anmeldung und Ratenbegrenzung und einen eigenen Eintrag in jeder Firewall. Ein API-Gateway sammelt das an einer Stelle: ein Eingang für viele Dienste. Diese Lektion baut es mit YARP, der Reverse-Proxy-Bibliothek von Microsoft für ASP.NET Core.
Was ein Gateway übernimmt
Microsofts Leitfaden zu API-Gateways im Azure Architecture Center nennt drei Aufgaben, die ein Gateway übernehmen kann:
- Routing (Gateway Routing): Anfragen nach Pfad, Host oder Methode an den richtigen Dienst weiterleiten. Der Browser kennt eine Adresse, die Dienste dahinter können umziehen, sich teilen oder zusammenwachsen.
- Bündeln (Gateway Aggregation): mehrere Antworten zu einer zusammenfassen. Das spart einem Client viele kleine Aufrufe.
- Querschnittsaufgaben (Gateway Offloading): Anmeldung prüfen, Raten begrenzen, TLS beenden, Kopfzeilen bereinigen, protokollieren. Was jeder Dienst bräuchte, steht einmal am Eingang.
Zwei Dinge gehören nicht ins Gateway. Fachliche Regeln: Ein Gateway, das entscheidet, ob ein Angebot gesendet werden darf, ist ein zweiter Monolith am Eingang. Und das alleinige Vertrauen: Prüft nur das Gateway die Anmeldung und vertrauen die Dienste dahinter jedem, der sie erreicht, reicht ein Fehler im Netz für einen Einbruch. Nach Zero Trust aus Lektion 4.8.1 prüft jeder Dienst selbst; das Gateway ist eine Prüfung mehr, nicht die einzige.