Kolumne WebTales

Was ist ein API Gateway – und wofür kann ich es einsetzen?

Niko Köbler

In den letzten Monaten ist der Begriff des „API Gateways“ immer populärer geworden, und das in ganz verschiedenen Kontexten. Was ist so ein API Gateway, was kann es und wann und wofür sollte (kann) ich es einsetzen? Und ist das was Neues oder gibt’s das schon länger? Zeit, sich mit dem Begriff und ein paar Einsatz-Szenarien auseinander zu setzen.

Proxy: Request Forwarding/Distribution und Protokoll-Übersetzung

Der Einsatz als Proxy ist sicherlich das einfachste und am weitesten verbreitete Szenario (und die Basis für alle weiteren). Hierbei werden eingehende Requests auf mein API einfach zu einem hinter dem Gateway liegenden Service weitergeleitet. Das kann verschiedene Gründe haben. Meist möchte ich die intern verwendete URL nicht nach außen geben, bzw. mir die Austauschbarkeit der Service-Implementierung hinter dem API offen lassen. Ist z.B. ein Customer-Service über die URL http://api.mydomain.tld/customer in einer bestimmten Version erreichbar, kann der Service gegen eine neue Implementierung – vorausgesetzt die Kompatibilität bleibt erhalten – mit einer anderen internen URL ausgetauscht werden, ohne dass die Konsumenten des Service über die Änderung informiert werden müssen. Denn für diese hat sich ja aufgrund des API Gateways nichts geändert.

Wenn hinsichtlich der Versionierungs-Semantik die verschiedenen Service-Versionsinstanzen völlig unterschiedlich implementiert sind, kann ein API Gateway einen einheitlichen Versionierungs-Mechanismus zur Verfügung stellen und dann z.B. über einen Header oder URL-Part den Service-Aufruf an die richtige Implementierung verteilen.

Ein anderes Proxy-Szenario kann die Protokoll-Übersetzung sein. Sollen Clients, die unser API nutzen, Nachrichten abliefern, die wir intern z.B. über ein Messaging-System weiterverarbeiten wollen, kann das API Gateway eine HTTP-Schnittstelle bereitstellen und die entgegengenommenen Daten über ein z.B. proprietäres Messaging-Protokoll an die Queue oder das Topic weiterleiten, ohne dass die Clients dieses implementieren müssen. Eine schöne Art der Entkopplung von Protokollen.

Im Bereich des Serverless Computing, im Speziellen für AWS Lambda, übernimmt das (AWS) API Gateway die Aufgabe, den einkommenden Request in ein für die Lambda-Funktion verständliches und verarbeitbares Event zu übersetzen und damit die Funktion aufzurufen. AWS-Lambda-Funktionen sind rein Event-basiert und kennen keinen HTTP Request/Response.

Web Tales

Niko Köbler

In der Kolumne Web Tales gibt Niko Köbler (freiberuflicher Software-Architekt) Anstöße zur Web-Entwicklung mit JavaScript, Java & Co. Aus der Praxis, für die Praxis!

Bisher erschienen:

Mocking

Entwickle ich ein neues (oder erweitere ein bestehendes) API, so möchte ich meinen Konsumenten meist sehr frühzeitig eine benutzbare Version zur Verfügung stellen, jedoch ohne großen initialen Entwicklungs- und Deployment-Aufwand zu betreiben. Ein API Gateway sollte in der Lage sein, die Requests mit Mocks zu beantworten. Je nach Flexibilität und Funktionsumfang des API Gateways können entweder nur statische Responses zurückgesendet werden, oder sogar auf verschiedende Request-Pfade/-Payloads mit unterschiedlichen Responses geantwortet werden. Das hilft den Konsumenten, früh die API-Nutzung zu implementieren und das dann fertiggestellte API auch so früh wie möglich produktiv zu nutzen, ohne noch viel Zeit für die Implementierung verstreichen zu lassen.

Service Composition

Unsere API-Nutzer, also die Clients, möchten mit möglichst wenig Aufwand möglichst viele Daten bekommen – bestenfalls alle Daten mit nur einem Request. Wenn unser System nun aber in einer Microservice-Architektur implementiert ist, sind ggf. mehrere interne Requests nötig, um alle Daten zu erhalten. Als Beispiel soll ein Szenario aus einem Webshop dienen. Hier möchte ein Client mit nur einem Request alle Information zu einem Produkt erhalten. Intern sind die Daten aber über mehrere Services abzurufen: Produktstammdaten, Preise, Lagerinformationen, etc. Hier kann nun ein API Gateway nach außen eine Produkt-Schnittstelle anbieten, z.B. unter dem Pfad `/product/4711`, die dann aber die einzelnen internen Services aufruft und die Daten gemeinsam dem anfragenden Client zur Verfügung stellt.

Model Transformation

Sehr häufig unterscheidet sich das Domänen-Datenmodell, welches ich über mein API nach außen geben möchte, von dem Modell, wie es intern im Service verwendet wird. Also müssen die Objekte vom internen in das externe Format, oder umgekehrt, transformiert oder gemappt werden. Diese Aufgabe kann ein API Gateway auch sehr gut übernehmen. Der Vorteil hierbei ist, dass die Service-Implementierung nichts von dem externen bzw. öffentlichen Format kennen muss. Der Nachteil dabei ist aber, dass es eine Kopplung zwischen API Gateway und Service gibt, da das API Gateway das Format der Service-Implementierung kennen muss. Ändert der Service sein Datenformat, muss zwangsläufig auch das API Gateway diese Änderung umsetzen und neu deployed werden. Damit bin ich schnell wieder bei einem (verteilten) Monolithen (aka „Big Ball of Mud„).

Device Optimization

Eine spezielle Art der Model Transformation ist die Device Optimization, bei der die Daten für die konsumierenden Client Devices aufbereitet und optimiert werden. Als Beispiel möchte ich hier, wie so oft im Microservice-Umfeld, Netflix bemühen, die einen sehr hohen Wert auf die Optimierung ihrer Daten für die jeweiligen Devices legen. Die User-Experience für Spielekonsolen-Nutzer ist eine andere, als für Leute, die vorm Rechner sitzen, und wiederum anders für User, die Filme mit einem Tablet schauen. Netflix hat dafür im API Gateway sogenannte Device Endpoint Adapter eingebaut, die je nach anfragendem Client-Device die Daten für das optimale UX aufbereiten.

Wie erwähnt, ist diese Art der Nutzung sicherlich sehr speziell. Wenn ich dieser Anforderung aber gerecht werden möchte (oder muss), ist sie durchaus den Aufwand wert. Nähere Infos zum Netflix API Gateway finden sich im Netflix Techblog [hier] und [hier].

Authentifizierung und Autorisierung

Möglicherweise soll die Nutzung unserer APIs nicht für jedermann möglich sein und nur einem bestimmten Anwenderkreis zur Verfügung stehen. Also müssen die Nutzer bzw. Clients in irgendeiner Art und Weise erkannt (authentifiziert) und die Nutzung eines APIs erlaubt (autorisiert) werden, ggf. aufgrund bestimmter Rollen. Das API Gatway ist hier eine gute Möglichkeit, die Authentifizierung und Autorisierung vorzunehmen und den Client-Request entsprechend weiterzuleiten oder auch abzuweisen. Im Falle der Weiterleitung dann natürlich mit den Informationen über den authentifizierten Aufrufer. Siehe hierzu auch mein Vortrag über Single-Sign-On für Microservices von der W-JAX 2016.

Querschnittsthemen Caching & Logging

Wenn jeder Aufruf unseres API durch das Gateway geht, ist das auch ein idealer Ort, an dem ich die Aufrufe protokollieren bzw. loggen kann, um so z.B. eine Request-basierte Abrechnung zu ermöglichen.

Häufige Aufrufe eines dezidierten APIs bzw. einer Ressource/URL können auch in einem API Gateway gecached werden, um so die nachgelagerten Systeme zu entlasten – vorausgesetzt, die Requests liefern für die zu cachende Zeit die identischen Informationen zurück. Zu beachten ist allerdings, dass die zu cachenden Response-Objekte evtl. nutzerabhängig zu verwalten sind.

Fazit

Schaut man sich die oben genannten Punkte an (die sicherlich nicht abschließend sind), so wird man sehr schnell zum dem Schluss kommen, dass vieles davon an Szenarien aus der EAI/Integrations-Welt erinnert. Forwarding, Service-Komposition, Transformation, Authentifizierung, etc. wurden in der Vergangenheit sehr oft von einem Tool namens „Enterprise Service Bus“ (die Älteren unter uns werden sich erinnern) übernommen. Dieses Wort ist aber irgendwie aus der Mode gekommen und oftmals auch negativ besetzt, da häufig – wenn falsch eingesetzt – ein großes, schwerfälliges Etwas damit assoziiert wird. Ein ESB muss nicht immer schlecht sein, in vielen Projekten hat er – richtig eingesetzt! – durchaus seine Berechtigung (in vielen Projekten aber auch nicht).

In der Tat nutzt auch so mancher ESB-Produktanbieter den aktuellen Hype um das Schlagwort „API Gateway“ aus und benennt sein Produkt, das ehemals „nur“ eine EAI-Bibliothek oder ein ESB war, nun „API Gateway“ oder „API Management Tool“. Ob zu Recht oder nicht, darf jeder für sich selbst entscheiden – ich finde es etwas kurios. Das hat nichts von „Lösung anbieten“, sondern mehr was von „Geld verdienen“.

Ich habe bewusst versucht, hier keine Produkt- oder Projektnamen zu nennen. Jedes Unternehmen und jedes Projekt muss sich selbst darüber klar werden, welche Anforderungen mit Hilfe eines API Gateways, wenn überhaupt, abgedeckt werden sollen, und welche Lösungen dafür in Frage kommen. Das kann letztendlich ein kommerzielles Produkt sein oder aber auch eine frei verfügbare Open Source Software. Sogar eine eigene Implementierung kann sinnvoll sein, wenn die Anforderungen es erlauben oder gar erfordern.

Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Kommentare
  1. Rainer Witzgall2017-05-26 13:53:32

    Hallo Herr Köbler, ich glaube eine weitere sehr sinnvolle Anwendung von API Gateways ist die Verschlüsselung der Daten während der Übertragung und in der Cloud. Das macht m.E. besonders Sinn bei Cloudspeichern wie dropbox, Office 365 und Cloudanwendungen wie Salesforce. Freue mich auf Ihre Antwort!
    Beste Grüße
    Rainer Witzgall

  2. Niko Köbler2017-06-01 08:56:54

    Hallo Herr Witzgall,
    vielen Dank für Ihren Kommentar.

    Was genau meinen Sie mit Verschlüsselung hier? Die Transport-Verschlüsselung via SSL/TLS oder die Verschlüsselung der Daten selbst, also des Payloads?

    Im ersten Falle bin ich bei Ihnen, gehe mittlerweile aber eigentlich implizit davon aus, dass wir nur noch über HTTPS kommunizieren (sollten), deshalb habe ich es nicht explizit erwähnt.
    Im zweiten Fall ist es IMO die Aufgabe des Absenders und des Empfängers, sich um Ver- und Entschlüsselung der Daten zu kümmern, da darf das API Gateway nicht dazwischenfunken, ansonsten hätten wir keine Ende-zu-Ende Verschlüsselung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.