API-Entwurf und -Bereitstellung in der Praxis Das ABC des API-Designs
Anbieter zum Thema
Die Lernkurve beim Entwurf von APIs ist steil. Stolperfallen gibt es wie Sand am Meer. Der Erfolg steht und fällt mit der richtigen Herangehensweise.

APIs bieten eine schnelle und einfache Möglichkeit, Software in Code zu steuern, um die reibungslose Interoperabilität von Anwendungen zu gewährleisten, die von verschiedenen Teams entwickelt werden. APIs erlauben es ihren „Verbrauchern“, auf die interne Funktionalität eines Systems in Code zuzugreifen, ohne seinen internen Aufbau genau zu kennen.
Durch das Veröffentlichen von APIs können Unternehmen die Funktionalität ihrer Lösungen „unter der Haube“ weiter verbessern, ohne bei den „Verbrauchern“ der APIs Änderungen an deren Code zu erzwingen oder diese miteinander erst absprechen zu müssen.
Vor dem Aufkommen von APIs war die Aufgabe, zwei IT-Systeme zur Zusammenarbeit zu überzeugen, immer ein individuelles Projekt, welches Wochen oder Monate in Anspruch nehmen konnte. Im Wesentlichen schrieb ein Entwickler eine eigene Software, damit die beiden Systeme, die unterschiedliche Protokollsprachen nutzten, miteinander interagieren konnten; und mit jedem Bugfix oder einer sonstigen Aktualisierung eines der Systeme war ein Update der Middleware vonnöten.
Noch vor sieben oder acht Jahren, in den Anfängen der komponentenbasierten serviceorientierten Architekturen (SOA) war jede Integration im Unternehmensumfeld ein separates Produkt. Diese Art, Geschäfte im Schneckentempo zu machen, können sich heutige Unternehmen nicht mehr leisten. APIs bieten einen standardisierten Ansatz, der die spröden organisatorischen Grenzen flexibilisiert und die betroffenen Wirtschaftseinheiten „agilisiert“.
Doch damit dies gelingt, müssen die Entwickler gewisse Design-Prinzipien beachten. Die meisten Unternehmen beginnen eigentlich als API-Konsumenten. Sie greifen auf APIs zu, die andere Organisationen bereitstellen, und sind nur mit jenen vertraut. Doch nach und nach werden alle Organisationen einer bestimmten Größenordnung selbst zu API-Anbietern. Das ist ein Weg voller Überraschungen und Stolperfallen. Denn die Lernkurve beim Entwurf von APIs ist steil.
API-Design auf den Punkt gebracht
Das Erstellen einer API ist ein Arbeitsablauf, der sich im Grunde genommen aus sechs klar umrissenen Phasen zusammensetzt:
- Phase 1 – Zielsetzung: Wer die Eckdaten richtig wählt, hat die Weichen auf Erfolg gestellt.
- Phase 2 – Designen und Prototypisieren: Das Grundgerüst der API steht.
- Phase 3 – Entwickeln: Die erste Implementierung nimmt Gestalt an.
- Phase 4 – Veröffentlichen: Auf die Implementierung folgt die Bereitstellung.
- Phase 5 – Verbrauchen: Die ersten Zugriffe in der Produktion stellen die ultimative Feuerprobe dar. Wird die API richtig skalieren? Das wird sich erst noch zeigen.
- Phase 6 – Analysieren: Observability und Datenanalyse bilden das Feedback-Loop für künftige Iterationen der API-Entwicklung.
Der Entwurf einer API beginnt logischerweise mit der Zielsetzung: dem Formalisieren der Anforderungen und der grundlegenden Eckdaten.
Den Ausgangspunkt für den Entwurf einer API bildet eine klar definierte Domänensemantik: eine konkret festgelegte Bedeutung syntaktisch gültiger Zeichenketten aus dem Kontext der entstehenden API.
Die Zielsetzung definiert die gewünschten Leistungsmerkmale der API. Diese Entscheidung ist in der Praxis ein Kompromiss zwischen Eigenschaften wie Simplizität, Skalierbarkeit, Wartungsfreundlichkeit, Performance und anderen.
Als Nächstes müssen sich die Entwickler auf einen Architekturstil einigen (zum Beispiel ereignisgesteuert, URI-CRUD-basiert oder eine Hypermedia-API etc.) und zu guter Letzt die Konventionen der API (z.B. Benennungsregeln, das URI-Format und andere) in dem sogenannten Style Guide erfassen.
Als Nächstes folgt das Prototypisieren der API, die Entwicklung, Implementierung und die Bereitstellung. Mit den Zugriffen der ersten API-Verbraucher ist die erste Erfassung von Daten für Analytics-Zwecke möglich. Das Feedback-Loop sollte in die nachfolgenden Iterationen der kontinuierlichen Entwicklung und Bereitstellung hineinfließen.
Einige Anwendungsarchitekturen erfordern zusätzliche Infrastrukturbausteine, um die Performance, Sicherheit und Skalierbarkeit der API-Bereitstellung zu gewährleisten: API-Gateways und Service-Meshes.
API-Gateways
API-Gateways dienen zur Verbindung von Cloud-Anwendungen und -Diensten als eine universelle Schnittstelle für die Verwaltung und Weiterleitung von API-Anfragen. Zu den bemerkenswerten Akteuren in diesem Bereich gehören DevOps Faith mit Open-Source-Lösungen wie KrakenD, einem Ultra-High-Performance-Gateway, und das stark VC-finanzierte Kong mit dem gleichnamigen API-Gateway. Darüber hinaus gibt es unzählige etablierte Anbieter, von großen Tech-Unternehmen wie Google mit Apigee, Amazon mit AWS API Gateway bis hin zu Salesforce mit MuleSoft.
Ein API-Gateway vermittelt die Kommunikation zwischen einem Client, der eine API verbrauchen möchte, und dem betreffenden API-Endpunkt. Jede API-Anfrage muss dieses Gateway erfolgreich durchlaufen, damit sie ausgeführt werden kann. Das Gateway wertet jede solche Anfrage des Clients und (üblicherweise auch) jede Antwort der API anhand einer Vielzahl von Richtlinien aus. In diesem Sinne stellt ein API-Gateway einen zusätzlichen Netzwerk-Hop auf dem Pfad der Datenebene zwischen den beiden Endpunkten der Kommunikation dar.
Die Bereitstellung eines API-Gateway erfolgt auf einem separaten System (sei es in einer separaten VM oder in einem separaten Pod), abgetrennt von den betreffenden API-Endpunkten und Clients.
API-Gateways stellen die interne und externe Konnektivität von Diensten bereit und können dabei drei grundlegende Aufgaben erfüllen:
- APIs als einen Dienst bereitstellen;
- eine Abstraktionsebene bilden;
- Netzwerkrichtlinien für die Kommunikation zwischen API-Endpunkten und Clients durchsetzen (das beinhaltet den Verbindungsaufbau, die Zugriffssicherung sowie die Verschlüsselung und Überwachung des Netzwerkverkehrs).
Die praktische Implementierung moderner APIs in Web-Anwendungen stützte sich bisher in konkreten Anwendungsfällen typischerweise auf ein API-Gateway sowohl innerhalb (Ost-West) als auch außerhalb des betreffenden Rechenzentrums (Nord-Süd). Das API-Management beschränkte sich dementsprechend auf den Umgang mit API-Gateways. Das ist lange nicht mehr der Fall (siehe dazu Kapitel „API-Toolchains“ in diesem eBook).
Service-Mesh-Infrastrukturen
Zur Verwaltung verteilter Anwendungsinfrastrukturen durch einen Cloud-Orchestrierer ist ein leistungsstarker dynamischer Service-Mesh unumgänglich (Service-Netz). Dabei handelt es sich um eine Virtualisierungsebene verteilter Konnektivität zur Gewährleistung kontinuierlicher Dienstverfügbarkeit.
Kubernetes setzt auf Istio auf, dem quelloffenen Service-Mesh von Google. Beide Lösungen stammen aus dem Hause Google und zählen zu den prominentesten Open-Source-Projekten aller Zeiten. Die hohe Popularität des Cloud-nativen Orchestrierers hat auch Istio zu einer hohen Akzeptanz verholfen. Istio hat jedoch den Ruf, zu umständlich und zu unflexibel zu sein.
Sowohl OpenShift Kubernetes von Red Hat, HPE Ezmeral als auch VMware Tanzu Service Mesh nutzen Istio als eine Abstraktionsebene zum Verwalten von Microservices in Kubernetes-Workloads. Als Antwort auf die Unsicherheit rund um die Governance von Istio hat Microsoft eine eigene quelloffene Service-Mesh-Implementierung in Googles Cloud-nativer Sprache Go/golang entwickelt und im August des vergangenen Jahres (2020) veröffentlicht: das Open Service Mesh.
Bei Microsofts Open Service Mesh (kurz für Service Mesh Interface) handelt es sich um eine quelloffene Referenzimplementierung von SMI auf der Basis von OSM (Open Service Mesh). „SMI ist (...) sehr beliebt und wir dachten, dass das Ökosystem genug Raum für eine Referenzimplementierung von SMI hergibt, bei der die Mesh-Technologie in erster Linie diese SMI-APIs implementiert und sie für Kunden in ein bestmögliches [anbieteragnostisches] Erlebnis verwandelt“, kommentierte Gabe Monroy, Director of Partner Management für Azure Compute bei Microsoft und CNCF-Vorstandsmitglied.
SMI versteht sich als eine Sammlung von CRDs (Custom Resource Definitions von Kubernetes) und Extension API Servern, die sich auf jedem Kubernetes-Cluster anbieteragnostisch eben einrichten und mit Standardtools bearbeiten lassen. Auf diese Weise können Benutzer in ihren Anwendungen die Service-Mesh-Technologie verwenden, ohne sich an eine bestimmte Implementierung irreversibel binden zu müssen.
OSM implementiert das Service Mesh Interface (SMI) zum Absichern und Verwalten von Microservice-Anwendungen. Hierzu macht sich OSM ein Tool namens Envoy zu Nutze, welches genauso wie Kubernetes unter der Schirmherrschaft der CNCF (Cloud Native Computing Foundation) entwickelt wird. Damit ist Microsoft ein schlauer Schachzug gelungen.
Das OSM-Projekt baut auf den Ideen und Implementierungen vieler Cloud-nativer Ökosystemprojekte auf, darunter Linkerd, Istio, Consul, Envoy, Kuma, Helm und die SMI-Spezifikation. Die Steuerebene von OSM implementiert das xDS von Envoy und ist mit SMI-APIs konfiguriert. OSM fügt einen Envoy-Proxy als Sidecar-Container neben jeder Instanz einer Anwendung ein.
Die Datenebene (die Gruppe von Envoy-Proxys, die als Teil von OSM ausgeführt werden) führt Zugriffssteuerungsrichtlinien aus, implementiert die Routing-Konfiguration und erfasst Metriken. Die Steuerebene programmiert die Datenebene, und zwar kontinuierlich, um sicherzustellen, dass Richtlinien und Routing-Regeln auf dem neuesten Stand sind und die Datenebene fehlerfrei funktioniert.
Zur Verwaltung des Zugriffs externer Nutzer auf die Dienste eines Kubernetes-Clusters dient in Kubernetes ein API-Objekt namens Kubernetes Ingres. Es stellt Routing-Tabellen für die regelbasierte Steuerung von Datenflüssen und Dienste wie die Lastverteilung bereit.
Das Hauptproblem beim Einsatz des API-Objektes Kubernetes-Ingress liegt in der Tatsache begründet, dass es nicht von der Istio-Steuerungsebene verwaltet werden kann, sodass Istio-Funktionen wie Routing-Regeln, verteilte Ablaufverfolgung, Telemetrie und Richtlinienprüfung bei Ingress nicht verfügbar sind.
Für den Einsatz mit Azure Kubernetes Service empfiehlt Microsoft derzeit nach wie vor Istio, Linkerd oder Consul. Dies ist nicht der einfachste Ansatz. Denn zum Verwalten des Service-Mesh werden sowohl eine separate virtuelle Maschine als auch ein laufendes Kubernetes-Cluster auf AKS benötigt. SMI (Service Mesh Interface) soll das Problem lösen. Es stellt einen Standardsatz von Schnittstellen zum Verknüpfen von Kubernetes mit Service-Meshes bereit. Azure unterstützt bereits SMI, da das Kubernetes-Team die Entwicklung geleitet hatte.
Ein leistungsstarkes Service-Mesh ist das ultimative Geheimrezept zur Gewährleistung elastischer Skalierbarkeit von Cloud-Anwendungen. Die quelloffene SMI-konforme Implementierung von Open Service Mesh von Microsoft löst für Cloud-Nutzer gleich zwei drückende Probleme: die zu hohe Komplexität bestehender Lösungen für die agile Bereitstellung verteilter containerisierter Microservices und die bisher unausweichliche Abhängigkeit des Orchestrierers von einer konkreten Service-Mesh-Implementierung.
Fazit
Durch das Veröffentlichen von APIs können Unternehmen die Funktionalität ihrer Lösungen „unter der Haube“ weiter verbessern, ohne bei den „Verbrauchern“ der APIs Änderungen an deren Code zu erzwingen. Doch auch die APIs müssen mit der Zeit gehen. Eine Quadratur des Kreises?
Mit den richtigen Tools ist auch die Quadratur des Kreises im Rahmen der Machbarkeit. Einige davon stellen wir in unserem eBook „API-Development“ vor, dem dieser Beitrag entnommen ist.
(ID:47847673)