API Management

Von: Thomas Bayer
Datum: 22. April 2018
Aktualisiert: 26. Juni 2019

Teil 1.) Einführung ins API Management

Dieser Artikel unterstützt dich bei der Auswahl eines passenden API Management Produktes für dein Unternehmen. Typische Aufgaben und Verantwortlichkeiten des API Managements werden aufgezählt und die Komponenten und Features beschrieben. Am Ende dieses Artikels gibt es eine Checkliste für die Anforderungen.

Nicht jeder Anbieter versteht unter API Management das Gleiche. Das wird am Funktionsumfang und den Projektbeispielen deutlich. Die wesentlichen Merkmale haben die meisten Produkte aber gemeinsam.

1 Aufgaben des API Managements

Das API Management kann die in diesem Abschnitt aufgeführten Aufgaben und Verantwortlichkeiten übernehmen. Nicht jedes Produkt auf dem Markt unterstützt alle der beschriebenen Aufgaben.

1.1 Sicherheit

Mit dem API Management lassen sich Services schützen. Eine typische Aufgabe ist die des „Edge“ Gateways, das zwischen Unternehmen und dem Internet typischerweise in einer Demilitarisierte Zone (DMZ) angesiedelt ist. Ein API Gateway kann Consumer authentifizieren und Anfragen autorisieren. Das Format und der Inhalt von Anfragen kann gegen Formatbeschreibungen (Schema) geprüft (validiert) werden. Die Transportverschlüsselung mit TLS bzw. SSL kann ebenfalls ein API Gateway übernehmen.

1.2 Monitoring

Das API Management kann Kennzahlen sammeln und diese in einer Konsole visualisieren oder dem Enterprise Monitoring zur Verfügung stellen. Die Verfügbarkeit der Services kann ebenfalls über das Monitoring überwacht werden.

1.3 Logging

Alle Aufrufe, die über API Gateways laufen können erfasst und in ein Log geschrieben werden.

1.4 Abrechnung

Die Nutzung einer Schnittstelle kann Fallbezogen abgerechnet werden. Dafür muss jeder Aufruf eines Service erfasst und einem Consumer zugeordnet werden. Später dienen die Daten für der Abrechnung.

1.5 Routing

Aufrufe können vom API Management an verschieden Backends weitergeleitet werden. Beispielsweise können Aufrufe an verschiedene Versionen eines Backends weitergegeben werden.

1.6 Orchestration

Bei einer Orchestration steuert ein übergeordneter Service Aufrufe an nachgeordnete Services.

1.7 Transformation

Bei einer Transformation wird eine Anfrage oder eine Antwort von einem Format in ein anderes umgewandelt.

1.8 Beschränkung des Zugriffs

Der Zugriff auf ein API kann mit Rate Limits und Quotas beschränkt werden. Beispielsweise können den Nutzern verschiedene Tarife (Plan) angeboten werden, die den Zugriff auf 1.000 Aufrufe am Tag beschränken oder einen unlimitierten Zugriff erlauben.

Einige der hier aufgezählten Aufgaben können auch von Produkten anderer Software Kategorien übernommen werden. Beispielsweise kann Routing und Transformation ein Integration Framework übernehmen. Für die Orchestration kann auch eine Workflow oder Processengine eingesetzt werden.

2 Komponenten

Ein API Management kann sich aus mehreren Komponenten wie Gateway, Katalog und Developerportal zusammensetzen. Die folgenden Abschnitte stellen die verschiedenen Komponenten unabhängig von einem konkreten Produkt kurz vor.

Der Funktionsumfang der Konsolen unterscheidet sich von Produkt zu Produkt erheblich. Auch die Aufteilung der Funktionen auf die Komponenten ist oft unterschiedlich.

2.1 API Gateway

API Gateways sind die wichtigste, zentrale Komponente einer API Management Lösung. Technisch ist ein API Gateway ein reverse Proxy, also ein Proxy, der nicht hinter einem Browser sondern vor einem Server platziert wird. Im Gegensatz zu einem „normalen“ reverse Proxy versteht ein API Gateway nicht nur etwas von HTTP sondern auch von APIs also von REST, JSON oder auch OAuth2. Platziert wird ein API Gateway vor REST Ressourcen und Services. Jeder Aufruf muss über das Gateway laufen, direkte Verbindungen, die nicht das Gateway passieren müssen z.B. über das Routing verhindert werden.

2.1.1. Verantwortlichkeiten und Aufgaben

Zu den Verantwortlichkeiten eines API Gateways gehören:

• Sicherheit
• Routing und Lastverteilung
• Monitoring und Logging
• Das Umschreiben (Rewriting) von Adressen
• Filtern von Inhalten
• Limitierung von Aufrufen ( Throttling)
• Zuordnen von Aufrufen zu Tarifen und Verträgen

Mache Gateways können weitere Verantwortlichkeiten übernehmen, die aber auch von anderen Komponenten übernommen werden können.

Die Entscheidung, welche Aufgabe von welcher Komponente übernommen wird, ist nicht immer einfach. Einige Hersteller versuchen möglichst viele Funktionen anzubieten, die teilweise aber nur rudimentär implementiert sind und besser von anderen Produkten übernommen werden können.

Es gibt Lösungen, die nur aus einem API Gateway bestehen oder bei denen mehrere API Gateways in eine größere Lösung, die vom API Management verwaltet wird eingebunden werden können.

Es gibt API Gateways auf der Basis des beliebten NGinx Servers, auf der Basis von HTTP Frameworks und eigene Implementierungen.

Ein Proxy basiertes API Gateway hat eine geringe Verzögerung zur Folge. In manchen Fällen, dann sich die Verzögerung durch ein API Gateway sogar verringern. Dieser Effekt kann durch Ressource Pooling oder Caching entstehen.

Die Produkte von Apigee, Mashape und Mashery verwenden Proxys. Eine alternativer Ansatz zu Proxies sind Agenten, die in Web oder Application Server als Erweiterung eingeklinkt werden.

2.2 Agents

Agenten werden als Plugin oder Filter in bestehende Systeme eingeklinkt. Die Verzögerung eines Aufrufs ist kleiner als die von reverse Proxies.

2.3 Hybrid

Reverse Proxy und Agent können beim hybriden Ansatz kombiniert werden.

2.4 Developer Portal

Ein Developer Portal richtet sich an Entwickler, die Services veröffentlichen oder in ihren Anwendungen die vom API Management zur Verfügung gestellten APIs nutzen möchten.

2.5 API Katalog

Im API Katalog können Entwickler APIs suchen und deren Beschreibung lesen oder Sie können die APIs dort direkt ausprobieren. Um ein API in eigenen Anwendungen nutzen zu können kann der Entwickler eine Subskription auf ein API eingehen. Bei dieser Gelegenheit kann dem zukünftigen Nutzer des APIs ein Nutzungsvertrag zum Akzeptieren präsentiert werden. Der Entwickler enthält bei einer Subskription Rechte und oft auch API Keys, die er für den Aufruf des APIs in seiner Anwendung verwenden kann.

2.6 Management Konsole

Management Konsolen richten sich an Administratoren und/oder die Anbieter von Services. Eine Management Konsole kann die folgenden Funktionen anbieten:

• Erstellen und Konfigurieren von Services
• Auswertung der Nutzung (Analytics)
• Diagramme und Statistiken zur Nutzung von Diensten
• Verwalten von API Gateways und anderen Komponenten
• Benutzerverwaltung
• Einsicht in Logs oder Ereignisse der Gateways

Die Management Konsole würde ich nicht überbewerten, da die Aufgaben der Management Konsole oft von anderen Infrastrukturkomponeten im Unternehmen übernommen werden können. Beispielsweise können Metriken zur Nutzung in die unternehmsweite Monitoringlösung übertragen und dort anstatt in der Konsole des API Managements ausgewertet werden.

2.7 Management API

Dass eine API Management Lösung selbst ein API anbietet, versteht sich eigentlich von selbst. Über ein Management API können z.B. Services und Benutzer eingerichtet, Konfigurationen verändert oder Statistiken abgefragt werden. Ein Management API ist nützlich, um Vorgänge zu automatisieren, z.B. wenn das API Management Bestandteil einer Cloud Infrastruktur ist.

3 Konzepte

In diesem Abschnitt werden Konzepte beschrieben, die in verschiedenen API Management Lösungen zu finden sind. Nicht alle Produkte verstehen unter den hier aufgeführten Begriffen das Gleiche. Die Beschreibungen in diesem Absatz passen aber zum Großteil der Produkte.

API Beschreibung mit Swagger oder Open API

3.1 Subscription

Ein Entwickler, der ein geschütztes API für sein Projekt verwenden möchte, kann im Developer Portal für dieses API eine Subscription einrichten. Der Entwickler bekommt für die Nutzung des APIs einen Schlüssel, den API Key, der mit jedem Aufruf des APIs mitgeschickt werden muss. Das Akzeptieren eines Nutzungsvertrages kann als Voraussetzung für das Anlegen einer Subscripton verlangt werden. Der Nutzungsvertrag kann die Bedingungen der Service Nutzung regeln und den Nutzer darauf hinweisen, das alte Service Versionen nur eine begrenzte Zeit zur Verfügung stehen. Entnutzerverträge sind besonders für öffentliche APIs interessant, die von Externen genutzt werden.

Subscriptions sind in der API Management Konsole sichtbar und können dort verwaltet werden. Nachdem ein Entwickler eine Subscription angelegt hat, kann diese per Autovalidation sofort frei geschaltet werden oder ein Administrator muss noch der Subscription zustimmen.

Einige Produkte verbinden das Eingehen einer Subscription mit der Auswahl eines Planes:

3.2 Plan

Ein Plan bedeutet in Deutsch soviel wie Tarif. Für öffentliche APIs gibt es oft einen stark eingeschränkten kostenlosen Plan, der z.B. nur 100 Aufrufe im Monat erlaubt. Ein zweiter Plan beinhaltet höhere Kontingente und ein dritter "Enterprise" Plan erlaubt vielleicht die uneingeschränkte Nutzung.

Abbildung 1: Auswahl eines Plans im API Katalog von Gravitee

In der Management Konsole können Pläne eingerichet und beschrieben werden. Für die Unterscheidung der einzelnen Pläne stehen Rate Limits und Quotas zur Verfügung.

3.3 Application

Eine Application faßt mehrere APIs zusammen. Mit nur einem einzigen API Key können alle APIs einer Application aufgerufen werden. Eine Application wird meist im Developer Portal vom Consumer eingerichtet. Danach kann der Entwickler der Application Subscriptions für einzelne APIs hinzufügen.

3.4 API Keys

Eine Authentifizierung über Benutzername und Passwort hat den Nachteil, dass ein Service nach der Nutzung in den Besitz des Passwortes kommt. Ein Ausweg ist die Verwendung eines API Keys. Der Entwickler eines Consumers kann z.B. über seinen Benutzer und sein Passwort bei einem API Katalog sich einen API Key für ein spezielles API erzeugen lassen. Diesen Key kann er dann in den Consumer anstatt seinem Passwort hinterlegen.

3.5 Policies

Zugriffsrechte, Quotas und Rate Limits lassen sich mit Policies Benutzern bzw. API Keys zuordnen. Bei einigen Produkten wie z.B. Gravitee werden mit Policies APIs oder auch einzelnen Routen Eigenschaften und Funktionen wie z.B. Caching zugewiesen.

3.6 Endpoint

Die Kombination von HTTP Methode und Pfad wird in einigen Produkten wie z.B. bei Tyk als Endpoint bezeichnet. Das Verhalten eines Endpoints kann z.B. um Black- und Whitelisting, Caching, Rewriting oder eine Transformation erweitert werden. Die Abbildung unten zeigt einen Endpunkt im API Designer der Tyk Lösung.

Abbildung 2: API Endpoint im Tyk API Designer

4 Features

Nicht alle Lösungen bieten dieselben Features. Einige sind jedoch typisch für API Gateways und API Management Lösungen.

4.1 Policies

Policies regeln die Nutzung eines APIs. Eine Policy kann die Authentifizierung eines Consumers erfordern und die Nutzung des APIs auf bestimmten Quotas wie z.B. maximal 1.000 Aufrufe pro Stunde begrenzen.

Policies können auch verwendet werden, um ein API mit weiteren Eigenschaften zu versehen (Gravitee.io).

4.2 URL Rewriting

Die Änderung einer URL ist eine der typischen Aufgaben eines API Gateways. Das Rewriting bereitet den Aufruf für die Weiterleitung an eine Zielschnittstelle vor.

Beispiel:

Umschreiben des URL Pfades von

nach

Für das Rewriting werden oft reguläre Ausdrücke verwendet.

4.3 Endpoint Discovery

IP-Adressen oder DNS-Namen der Backendservices können im API Management statisch hinterlegt oder dynamisch über ein Endpoint Discovery ermittelt werden. Die Discovery ist für den Betrieb in Verbinding mit einer Cloud nützlich. Die IP-Adresse eines Service kann sich in der Cloud mit jedem Neustart ändern. Eine statisch hinterlegte Adresse wäre dann ungültig und müßte manuell geändert werden. Beim Endpoint Discovery ist das API Management an eine Service Registry der Cloud angebunden und wird über Änderungen der Adressen informiert.

Das API Management Gravitee kann neu gestartete Services auch automatisch als API veröffentlichen.

4.4 Transformation

Transformation ist notwendig um ein API an eine Legacy Schnittstelle weiterzuleiten. Eine Transformation kann Anfragen und Antworten verändern. Beispielsweise kann der Inhalt des Bodys von XML nach JSON umgewandelt werden. Es lassen sich aber auch die HTTP Header-Felder und deren Inhalte Transformieren.

Für die Transformation gibt es mehrere Technologien. Mache Produkte bieten eine eigene deklarative Sprache für die Transformation an während andere Produkte bestehende Technologien wie z.B. JOLT oder eine Template Engine verwenden.

4.5 REST2SOAP

Ein REST2SOAP Gateway kann REST Anfragen an einen SOAP basierten Web Service weiterleiten oder umgekehrt eine SOAP Anfrage in den Aufruf einer REST Ressource umwandeln.

4.6 API Composing

Die Verzögerungszeit auch Latenz genannt zwischen Client und API ist besonders bei mobilen und Web Anwendungen kritisch. Man versucht daher möglichst jede Aktion im Client mit nur einer einzigen Anfrage an das API zu realisieren. Bei API Composing werden mehrere API Calls zu einer Anwort zusammengesetzt, damit auf der langsamen Strecke über das Internet zwischen API Gateway und Client nur ein Aufruf notwendig ist.

4.7 LoadBalancing und Failover

Die meisten API Gateways können Aufrufe an mehrere Instanzen eines Backendes verteilen. Im Fehlerfall kann das Gateways einen weiteren Versuch bei einem anderen Backend-System starten.

4.8 Circuit Breaker

Zum Schutz vor Überlastung kann die Weiterleitung an ein Backend zeitweise ausgesetzt werden. Bei Fehlern neigen HTTP Clients sowie einige Benutzer dazu die HTTP Anfragen einfach zu wiederholen. Dies führt zu noch mehr Last für das Backend. Um dem Backend eine Chance für eine Erholung zu geben, wird bei gehäuften Fehlern die Weiterleitung unterbunden. Schwellwerte für den Anteil an fehlerhaften Antworten oder für Verzögerungszeiten können das Auslösen eines Circuit Breakers triggern. Der Schaltkreis ist dann in Analogie zur Elektrik geöffnet: Es fließen keine Nachrichten mehr. Nach einer kurzen Zeitspanne wird der Schaltkreis wieder geschlossen und Aufrufe werden wieder an das Backend weiter geleitet. Die kurze Unterbrechung gibt dem Backend die Chance, das sich sein Betrieb normalisiert.

4.9 Logging

Die Aufrufe eines APIs können protokolliert und aufgezeichnet werden. Einige Produkte bringen selbst einen Speicher für diese Protokolle mit. Bei anderen Produkten können Standardprodukte für das Logging über Adapter oder Plugins genutzt werden. Einige Produkte erlauben z.B. das Logging mit ElasticSearch, Logstash und Kibana dem ELK-Stack oder in einer NoSQL Datenbank wie z.B. Apache Cassandra oder der MongoDB.

4.10 API Dokumentation

Fast ausnahmslos sind alle weit verbreiteten APIs gut dokumentiert. Das API Management erleichtert das Bereitstellen von API Beschreibungen. Fast jede API Dokumentation erlaubt das interaktive Ausprobieren des APIs, in dem mit wenigen Klicks ein Beispielaufruf gegen einen Life- oder Testservice abgesetzt werden kann.

Am weitesten verbreitet ist die API Beschreibung mit Swagger bzw. dem Open API Standard.

Das API Management kann das Testen von gesicherten APIs mit Test API Keys unterstützen oder mit eingeschränkten Policies, die nur eine kurze eingeschränkte Nutzung eines Service erlauben.

4.11 REST und/oder SOAP?

Alle Lösungen unterstützen heute REST und JSON. Das inzwischen veraltete XML basierte SOAP wird nur von einem Teil der Produkte unterstützt. Spielt SOAP und WSDL im Unternehmen noch eine entscheidende Rolle, kann die Unterstützung für SOAP basierte Web Services ein KO Kriterium für eine API Management Lösung sein. Wird SOAP nicht benötigt, stellt eine Web Services Unterstützung unnötigen Ballast dar und eine Lösung, die ganz auf neuen Technologien beruht wäre vorzuziehen.

5 Deployment

Beim Deployment gibt es große Unterschiede zwischen den Produkten.

5.1 On Premise

„On Premise“ bedeutet „vor Ort“ und beschreibt die konventionelle Art der Installation, bei der ein Unternehmen das API Management selbst auf eigenen Rechnern in der Firma betreibt. Mit einer On Premise Installation bekommt man die größtmögliche Kontrolle und behält die Daten im Unternehmen. Dafür hat der Betrieb mehr Arbeit mit Installation, Updates und anderen Wartungsarbeiten. Bei vielen Organisationen ist die Installation „vor Ort“ die einzige, die aus Gründen des Datenschutzes in Frage kommt.

Bei einer „On Premise“ Installation muss bei den meisten Produkten zunächst die Art der Installation ausgewählt werden, da einige Produkte mehrere Alternativen für die Installation angeboten werden. Eine Installation im Docker Container ist inzwischen ein „Must“ für fast jede Art von Server oder Infrastruktursoftware. So verwundert es nicht, dass fast alle Produkte in einem Docker Container betrieben werden können.

Der Betrieb als Web Anwendung in einem Application Server z.B. im Tomcat, Oracle WebLogic oder IBM WebSphere hat den Vorteil, dass das API Management auf die gleiche Weise wie andere Anwendungen installiert und betrieben werden kann.

Einige Produkte können über die Paketverwaltung von Linux bequem als Service installiert werden.

5.2 Cloud

Die Komponenten des API Managements können bei einem Cloud-Anbieter oder beim Anbieter der Lösung betrieben werden. Meist stehen mehrere Tarife zu unterschiedlichen Preisen zur Auswahl. Die Abrechnung erfolgt monatlich oder jährlich. In der Regel ist ein API Management in der Cloud in wenigen Minuten oder Stunden eingerichtet. Externe API Aufrufe gehen zunächst zum Cloudanbieter, werden dort geprüft und dann in die eigene Organisation oder zu einem anderen Endpunkt in der Cloud weitergeleitet. Da zwischen API Gateway und den eigentlichen Endpunkt eine große Distanz liegen kann, ist jeder Aufruf mit einer gewissen Verzögerung verbunden. Ein Deployment in der Cloud hat die folgenden Vorteile:

• Schnelle Einrichtung
• Gute Skalierbarkeit
• Reduzierter Betriebsaufwand

5.3 Hybrid

Eine Hybride Lösung verbindet die Cloud und eine lokale Installation. Beispielsweise können die API Gateways lokal betrieben werden, um die Latenzen (Verzögerungszeiten) kurz zu halten und die Konsolen für die Entwickler und Administratoren werden in der Cloud betrieben. Es gibt noch weitere Arten einer Hybriden Installation, bei der z.B. Gateways sowohl lokal als auch in der Cloud betrieben werden.

6 Performanz

Vorsicht ist bei einem Betrieb der Gateway Komponente in der Cloud angebracht. Besonders wenn der Aufrufer und das Target beide im Unternehmen angesiedelt sind und jeder Aufruf erst in die Cloud und von dort zurück ins Unternehmen geleitet werden muss. Eine hybride Installation mit Gateway im Unternehmen kann Verzögerungszeiten ( Latency) wesentlich begrenzen. Wird ein API externen Consumern zur Verfügung gestellt, fällt der Unterschied in der Verzögerung weniger gross aus. Je nach Art des APIs kann die Verzögerungszeit auch unkritisch sein.

7 Preise

Viele Anbieter wie z.B. Tyk locken mit einem begrenzten kostenlosen Tarif, der zum Ausprobieren oder sogar für kleine Installationen ausreichend ist. Eine komplett kostenfreie Nutzung bieten einige Open Source Anbieter wie z.B. Mashape mit Kong, WSO2 oder Gravitee an.

8 Anforderungen ans API Management (Checkliste)

Vor einer Entscheidung für ein API Management Produkt sollten die Anforderungen klar definiert sein. Bei der Aufstellung der Anforderungen sind die folgenden Fragen hilfreich:

• Wer nutzt meine APIs? Andere Abteilungen im eigenen Unternehmen, externe Partner oder eine größere anonyme Öffentlichkeit?
• Wird neben REST auch SOAP basierte Web Services betrieben?
• Welche Aufgaben soll das API Management übernehmen?
• Wird eine ausgewachsene API Management Lösung benötigt oder genügt ein einfaches API Gateway?
• Wird Support benötigt?
• Welche Statistiken werden benötigt?
• Sollen Daten der Nutzung und des Betriebes an ein zentrales Monitoring des Unternehmens weitergeleitet werden?
• Soll das API Management in die bestehende Betriebsinfrastruktur aus Monitoring, Alerting, Logging und Analyse eingebunden werden?
• Welche Authentifizierungsverfahren müssen unterstützt werden.
• Wie sollte die Security an die bestehenden Nutzerdatenbanken (LDAP) und Single Sign On Systeme angebunden werden?
• Wie schnell kann ich externen einen Zugang einräumen?
• Wie leicht lässt sich eine große Anzahl von Konsumern verwalten?
• Soll die Service Nutzung erfasst werden und die Daten für die Rechnungsstellung bereitgestellt werden?
• Soll der Umfang der Service Nutzung kontrolliert und begrenzt werde?
• Sind Nutzer zu authentifizieren und Aufrufe zu autorisieren?
• Soll die Verwaltung des API Lifecycles und der Versionen unterstützt werden?

8 Fazit

Wie bei jeden anderen jungen Markt auch, gibt es beim API Management eine unüberschaubare Vielzahl Produkten. Eine Bereinigung des Marktes hat durch die Übernahme von 3scale und apiman durch Red Hat und durch den Kauf von APIGee durch Google bereits begonnen. Es ist zu erwarten, dass in den nächsten Jahren weitere Aufkäufe die Anzahl der Produkte stark reduzieren werden.

Vor einer Produktauswahl sollte man sich über die Anforderungen im klaren sein und die Kriterien für eine Auswahl aufstellen. Eine Auswahl rein über die Abdeckung von Kriterien ohne ein Ausprobieren und Testen der Produkte birgt die Gefahr, Opfer der Werbung und der Produktbeschreibungen zu werden. Alle Produkte, bei der eine Installation oder ein Setup in der Cloud nicht innerhalb von kurzer Zeit möglich ist, oder deren Dokumentation unübersichtlich und unvollständig ist, können bei einem Test gleich aussortiert werden.