Was ist ein API Gateway?

[@markuskonrad]

Danke für das Video. Wie so oft in der IT. Viele Namen, gleiches Thema! :) Wer im Microsoft Umfeld zuhause ist, eine entsprechende Azure Subscription besitzt und mit API Management anfangen möchte kann ich nur wärmstens empfehlen einen Blick auf Azure API Management zu werfen. Sehr mächtig und mit den entsprechenden Backend Services extrem mächtig und flexibel. Sobald mal die ersten Pipelines stehen auch einfach zu warten/erweitern. Das geht natürlich auch alles mit AWS und Co., ich wollte nur mal ein Beispiel nennen, da du in deinem Video keines vorgeschlagen hattest.

[@thomas-bayer]

Hallo Markus, danke für deinen Tip zum Azure API Management. Schau ich mir mal an.

[@felixschneider608]

Gut erklärt, sehr hilfreich! Danke dir.

[@tinoredemann2403]

Hallo und voraus danke für deine Erklärungen.. Der Ton des Stiftes auf der Tafel ist grauenvoll, vielleicht wäre normale Kreide eine Alternative.. Mfg

[@predic8]

Danke für den Tip. Werde ich ausprobieren.

[@bCool-sl5cy]

Einen Restservice kann mit einem Interceptor geschützt werden. In diesem Video ist das Wort ZENTRAL: also mehrere Rest-API werden so zentral geschützt.

[@praetoriantribune]

Danke für die Erklärungen, aber ich konnte mir das Video nicht bis zum Ende ansehen. Ich kann dieses hohle Kratzen der Kreide auf der Tafel nicht aushalten. Bitte in Betracht ziehen zukünftig ein Whiteboard zu verwenden. :-)

[@wassollderscheiss33]

Wenn das Api-Gateway die Authentifizierung vornimmt, woher weiß es dann, welche Benutzer auf welche Api zugreifen dürfen? Führt das nicht zu einer Abhängigkeit dergestalt, dass alle Apis mit exakt gleicher Benutzerbasis jeweils ein eigenes Api-Gateway benötigen? Ich stelle mir vor, dass das für viele praktische Anwendungen darauf hinausliefe, dass so gut wie jede Api ein eigenes Api-Getway benötigte. In dem Fall kann man die Gateway-Funktionen evtl. besser direkt in die Api integrieren.

[@thomas-bayer]

Gute Fragen. Ich stimme dir zu, dass es manchmal Sinn macht Gateway Funktionen wie z.B. Authentifizierung in ein Backend zu integrieren beispielsweise mit Spring Security. Auch ein Gateway pro API kann Sinn machen. Service Meshes bauen auch auf dieser Idee auf. Es ist aber mit den meisten Gateways möglich, für jedes API einen anderen Benutzerkreis zugänglich zu machen. Wer auf welches API zugreifen darf wird oft nicht im Gateway konfiguriert, sondern in einer API Management Lösung oder über einen Verzeichnisdienst in Verbindung mit einem Token Service. Zu deiner eigentlichen Frage: Wo her weiß das Gateway wer ein API aufrufen darf? Bei Tokens z.B. bei JWT kann die Entscheidung im Gateway von Feldern des Tokens abhängig gemacht werden. Bespielsweise über die Zugehörigkeit zu einer Gruppe. Oder es kann hinterlegt werden, mit welchem API-Key welches API aufgerufen werden kann.

[@aytac81]

Über Authentifizierung (Beispiel jwt Token, erstellt über OAUTH2) + policies. Im Token können Claims verwendet werden um z.B. den Zugriff auf Endpunkte zu beschränken. Im Falle von OAuTh könnte pro Kunde eine App Registry erstellt werden, mit der dann wieder per Policy der Zugriff gesteuert wird.

[@philipptobiasschroder9547]

Stift!! 🤣

[@kurtmustii]

Das falsche Stift, es kreischt 😫