Was ist das API-Reifegradmodell?

Einige API-Reifegrad-Frameworks betonen bestimmte Dimensionen wie Sicherheit, Auffindbarkeit, Wartbarkeit oder PlatformEngineering. API-Management-Anbieter wie Kong, Tyk und Curity bieten API-Reifemodelle an, die auf ihre eigenen Lösungen abgestimmt sind, um Kunden dabei zu helfen, ihren Fortschritt bei der Einführung dieser Plattformen einzuschätzen. Andere Modelle sind breiter angelegt und können auf jedes Protokoll oder jede Architektur angewendet werden.

Anwendungsprogrammierschnittstellen (APIs), die Verbindungen zwischen getrennten Diensten und Anwendungen ermöglichen, sind eine zentrale Säule des Internets und helfen Entwicklern, Drittanbietertechnologien und Datenquellen zu nutzen, anstatt sie von Grund auf neu zu entwickeln. Sie ermöglichen zudem die Integration von Ressourcen, Daten, Sicherheit und Governance innerhalb von Organisationen und optimieren so interne Implementierungen und Teamübergreifende Kommunikation. Mehrere APIs können zusammen mit Bibliotheken, UI-Tools und anderen Komponenten kombiniert werden, um ein Softwareentwicklungskit (SDK) zu bilden, ein Set von Werkzeugen, das Entwicklern hilft, standardisierte Anwendungen schnell und zuverlässig zu erstellen.

API-Reifegradmodelle identifizieren und beschreiben spezifische strukturelle und technologische Innovationen sowie strategische Best Practices, die Organisationen helfen können, ausgefeiltere und robustere API-Systeme zu entwickeln und so Effizienz, Sicherheit und Interoperabilität zu verbessern. Sie dienen als Roadmap, die Unternehmen bei der Entscheidung hilft, welche Innovationen sie bei der Beschleunigung ihrer API-Entwicklung priorisieren sollten.

Das Richardson-Reifemodell, eines der meistzitierten Frameworks, bewertet die Einhaltung der RESTful-Prinzipien einer API über vier Reifestufen hinweg, wobei die höchste Stufe ein vollständig RESTful-System repräsentiert.

Im Jahr 2000 führte der Informatiker Roy Fielding REST ein, einen Architekturstil, der Funktionen wie eine einheitliche Schnittstelle, die Entkopplung von Client und Server, Zustandslosigkeit, Zwischenspeicherbarkeit und geschichtete Systeme fördert. Zusammen können diese Funktionen die Skalierbarkeit, Effizienz und Flexibilität innerhalb von Unternehmen verbessern und zu einem offeneren, Resilient und sichereren Internet beitragen, wenn es in größerem Maßstab implementiert wird. Moderne Versionen verwenden häufig HTTP zum Transport von Informationen und das für Menschen lesbare JSON-Format zur Organisation dieser Daten, obwohl auch andere Protokolle und Formate verwendet werden können.

Im Jahr 2008 entwickelte der Softwareingenieur Leonard Richardson auf diesem Rahmenwerk ein Modell, das konkrete technische Änderungen aufzeigt, die Unternehmen implementieren können, um die Anpassungsfähigkeit und Widerstandsfähigkeit ihres REST-API-Designs zu verbessern. Das Richardson-Reifemodell (RMM) "lädt dazu ein, die drei Web-Technologien – URI, HTTP und Hypermedia (auch bekannt als HTML) – als drei einzelne Technologien und nicht als Paket zu betrachten", sagte Richardson gegenüber IBM Think. Das Framework zeigt die praktischen Nutzen einer schrittweisen Implementierung jeder einzelnen Technologie auf, „da wir über diese Technologien verfügen, sie sehr beliebt sind und von nahezu jeder Programmiersprache umfassend unterstützt werden.“

Das Richardson-Reifemodell priorisiert die Implementierung von Ressourcen, bei der jede Ressource eine eigene URI gemäß den allgemeinen REST-Prinzipien erhält, die empfehlen, jeder Ressource eine eindeutige Identifikation zuzuweisen. Das RMM fördert außerdem die Verwendung von Antwortdokumenten, die den aktuellen Zustand einer API erfassen, anstatt Beschreibungsdokumente, die eine statische, vordefinierte Beschreibung einer API zu einem bestimmten Zeitpunkt präsentieren. Das Modell gilt im Allgemeinen für HTTP-basierte Webanwendungen, kann aber als konzeptionelles Framework auch in anderen Kontexten wie IoT-Netzwerken und Datenpipelines verwendet werden.

Das Richardson-Reifemodell verwendet vier Stufen, um zwischen verschiedenen Reifegraden zu unterscheiden, von einer non-RESTful-Architektur bis zu einer vollständig RESTful-basierten.

Level Null stellt ein nicht-RESTful-basiertes Design dar, das eine einzelne Funktion mit einem einzelnen Endpunkt (wie „/api“) und einem einzigen Befehl (meist POST) umfasst. Level Null ist zwar einfach zu implementieren, nutzt aber nicht die leistungsstärksten Funktionen von HTTP, einschließlich Verben, URIs und Statuscodes. Stattdessen wird HTTP lediglich als Transportmechanismus verwendet, wobei alle operativen Details dem Nachrichtenkörper selbst hinzugefügt werden.

Da diese Methode in der Vergangenheit bei XML-basierten RPC-Mustern (Remote Procedure Call) verwendet wurde, gaben Kritikern ihr den Spitznamen „Swamp of POX“ (einfaches altes XML). Die Idee ist, dass Funktionen und Daten bei fehlender Struktur und klaren Abgrenzungen zwischen Services leicht überladen und eng miteinander verknüpft werden können. Auf Ebene Null verfügt die API über keine Möglichkeit, auffindbare Ressourcen zu identifizieren oder offenzulegen, sodass API-Nutzer im Voraus wissen müssen, was verfügbar ist. Entwickler haben möglicherweise Probleme mit der Skalierung, Versionierung und Fehlerbehebung, da das einzelne Endgerät keine Informationen über sich selbst teilen kann.

Level eins führt mehrere URIs ein, die jeweils eine andere Ressource darstellen können. Es verwendet aber weiterhin nur ein einziges HTTP-Verb, typischerweise POST. Anstatt mit einem generischen „/api“-Endpunkt zu interagieren, können Kunden nun Endpunkte aufrufen, die bestimmten Ressourcen entsprechen – zum Beispiel „Produkte“, „/Warenkörbe“ oder „/Rechnungen“ in einem E-Commerce-Umfeld. Allerdings müssen Clients in der Regel immer noch ihre operative Absicht oder Aktionen im Nachrichtentext selbst übermitteln, anstatt einen vordefinierten Satz von HTTP-Verben zu verwenden.

Dieser Ansatz schafft klarere Grenzen zwischen den Ressourcen und verringert Unklarheiten darüber, welche Ressourcen den Kunden zur Verfügung stehen. Entwickler können jedoch leicht verwechseln, welche Aktionen ausgeführt werden können, da es kein standardisiertes Format für den Aufruf von URIs gibt. Auch die erste Ebene kann mit der Zeit umständlich werden, da Entwickler in der Praxis möglicherweise neue Endpunkte für einzelne Aktionen erstellen, wie z. B. „/productsUpdate“ oder „/productsDelete“. Diese Vorgehensweise kann dazu führen, dass sich URIs nach und nach anhäufen, was die Bereitstellung und Versionierung erschwert.

Schließlich macht das Modell Entwickler abhängiger von externer API-Dokumentation, denn obwohl Ressourcen unterschiedliche URIs zugewiesen bekommen, können sie nicht offenlegen, welche Aktionen interpretiert oder ausgeführt werden können.

Level zwei fügt HTTP-Methoden hinzu, eine standardisierte Reihe von Verben, die Entwickler zur Interaktion mit Daten und Diensten verwenden können. In vielen Konfigurationen können Clients vier grundlegende Befehle – erstellen, lesen, aktualisieren oder löschen – verwenden, um an jedem Endgerät verschiedene Aktionen auszuführen. Mithilfe von Headern können während des API-Aufrufs zusätzliche Informationen übermittelt werden, wie beispielsweise Inhaltstyp, bedingte Anforderungen oder Autorisierungsdaten.

Dieser Ansatz ist im Vergleich zu Level eins und Level null effizienter und besser organisiert, da die Benutzer ein Gefühl dafür haben, was die API leisten kann und wie Clients mit ihr interagieren können. APIs sind jedoch nicht in der Lage, diese Informationen in Echtzeitzu vermitteln – Benutzer können sich nur über ein externes Developer Portal über die einzelnen APIs informieren – was die Auffindbarkeit verringert. Dieser statische Ansatz kann auch zu Fehlabstimmungen führen, wenn die API-Dokumentation nicht mit den aktuellen Funktionen übereinstimmt.

Heutzutage arbeiten die API-Ökosysteme der meisten Unternehmen auf Ebene zwei, da diese Ebene ein Gleichgewicht zwischen Vorhersagbarkeit, Effizienz und Zugänglichkeit bietet. Es ermöglicht Unternehmen auch, die besonderen Funktionen von HTTP zu profitieren, wie zum Beispiel Caching (häufig genutzte Ressourcen lokal zu speichern, damit sie schnell abgerufen werden können), was zu erheblichen Leistungssteigerungen führt.

Level drei führt HATEOAS oder Hypermedia als Motor der Anwendung ein. Wenn ein Client einen API-Aufruf tätigt, antwortet die API mit einer dynamischen Liste von Optionen für verschiedene Aktionen und zugehörige Begriffe, ähnlich wie moderne Browser funktionieren. Diese Aktionen und Bedingungen werden innerhalb des Programms vermittelt, sodass Entwickler keine externe Dokumentation konsultieren müssen, um mehr darüber zu erfahren. Hypermedia-basierte Architekturen fördern zudem Interoperabilität, da externe Kunden einfach auf Dienste zugreifen können, ohne im Voraus zu lernen, wie man sie benutzt.

Gleichzeitig bringen Hypermedia-Steuerungen zur Laufzeit eine größere Komplexität mit sich: „Der Client muss nicht nur vorprogrammiert reagieren können, sondern auch die vom Server eingehenden Dokumente lesen und den Inhalt dieser Dokumente nutzen, um die Entscheidung über seine nächste Anfrage zu treffen“, sagte Richardson.

Der Aufbau und die Wartung von Hypermedia-Funktionen können aufgrund der dynamischen Struktur von Hypermedia kostspieliger und zeitaufwändiger sein. Die API antwortet auf Client-Anfragen mit einer Reihe von Links für weitere Aktionen, was betrieblich anspruchsvoller ist. Darüber hinaus unterstützen viele Client-Plattformen keine Hypermedia. Wenn ein Unternehmen HATEOAS einführt, müssen externe Benutzer möglicherweise kompatible Tools finden, bevor sie auf diese Dienste zugreifen können.

Heute wird HATEOAS am häufigsten von Bibliotheken, gemeinnützigen Organisationen, wissenschaftlichen Einrichtungen, Marktkoalitionen oder aufstrebenden Unternehmen (Organisationen, die versuchen, eine Branche zu revolutionieren) genutzt, sagte Richardson, weil es Offenheit und Interoperabilität fördert. Hypermedia kann auch intern verwendet werden, da es APIs und Aktionen für Benutzer leicht auffindbar macht, selbst für Benutzer, die keine Vorkenntnisse im API-Ökosystem haben. Manche Unternehmen bieten Hypermedia-APIs während ihrer Wachstumsphase an und schränken dann den Zugang ein, sobald sie mit der Monetarisierung ihres Produkts beginnen.

Die Branche wechselt zunehmend zu Alternativen wie GraphQL und gRPC für bestimmte Anwendungsfälle. Während 93 % der Entwickler angeben, dass sie in irgendeiner Form RESTful-Webdienste verwenden, verwendet laut dem Postman State of the API Report ein Drittel GraphQL und 14 % gRPC. GraphQL kann Anfragen von mehreren Microservice, sogar von Diensten, die in verschiedenen Umgebungen gehostet werden, intelligent abrufen und zu einer einzigen Antwort kompilieren, was die Effizienz steigert und Über- oder Unterprovisionierung verhindert. gRPC hingegen ist ideal für Streaming, Telemetrie und andere Anwendungsfälle, bei denen hohe Leistung und geringe Latenz im Vordergrund stehen.

Obwohl GraphQL und gRPC die dynamische Natur von Hypermedia nicht replizieren können, gehen beide Architekturen Schmerzpunkte im Zusammenhang mit Effizienz und Schemamanagement präziser an, weshalb einige Organisationen diese Implementierungen gegenüber vollständigen Hypermedia-Kontrollen priorisieren.

Im Richardson-Reifemodell kann der Übergang von einer API-Reifestufe zur nächsten sowohl Design- als auch technische Herausforderungen mit sich bringen. Der Prozess beinhaltet häufig das Refaktorieren des Servercodes, um mehrere URIs (Level eins) und mehrere HTTP-Methoden (Level zwei) zu berücksichtigen. Dies wird durch Aktualisierung von Routing-Regeln, Datenbankinteraktionen, Tests, Dokumentation und Controllern erreicht.

Unternehmen könnten damit beginnen, ihre aktuellen Endgeräte zu katalogisieren, zu ermitteln, welche Endgeräte modifiziert werden können, um den RESTful-Bedingungen zu folgen, und die erforderlichen Ressourcen und Verben festzulegen. Entwickler bauen möglicherweise eine neue Version auf der aktuellen Version des Unternehmens, damit Kundenanrufe während des Übergangs nicht unterbrochen werden. Ein umfassender Satz von Fehlercodes kann Benutzern auch helfen, sich mit neuen API-Endpunkten vertraut zu machen und Fehler zu beheben, ohne umfangreiche Dokumentationen konsultieren zu müssen.

Während sich das RMM auf spezifische technologische Implementierungen in RESTful-Systemen konzentriert, verfolgen Organisationsmodelle einen umfassenderen Ansatz und helfen Unternehmen dabei, sich auf eine gemeinsame Reihe von Prinzipien auszurichten, die Konsistenz, Ressourcenoptimierung und Anpassungsfähigkeit fördern. Strategische Reifegradmodelle können sich zwar je nach Unternehmen unterscheiden, ein gängiger Ansatz umfasst jedoch vier Ebenen:

In einfachen oder ad hoc entwickelten API-Ökosystemen reagieren Organisationen auf unmittelbare Probleme, anstatt im Rahmen eines einheitlichen API-Entwicklungsrahmens zu arbeiten. Entwickler erstellen und entfernen APIs nach Bedarf mit begrenzter zentraler Kontrolle, was zu Fehlausrichtungen sowie zu Problemen mit der Governance, der Sicherheit und der Observability führen kann. Mit wenig Einblick in die aktuelle API-Leistung können Teams Ressourcen nicht effektiv zuweisen oder für die Zukunft planen.

Standardisierte API-Ökosysteme führen eine konsistente Dokumentation, Namenskonventionen, Fehlercodes und Entwurfsmuster ein. Ein API Gateway kann verwendet werden, um Authentifizierung, Autorisierung und andere zentralisierte API-Sicherheit durchzusetzen. Entwickler können APIs im Rahmen der Governance-Struktur des Unternehmens problemlos hinzufügen, entfernen und pflegen und Komponenten nahtlos wiederverwenden und anpassen. Kunden können die verfügbaren Dienste leicht über ein Developer Portal und integriertes Onboarding entdecken und erfahren, was die allgemeine API-Akzeptanz erhöht.

Da es in dieser Phase jedoch nur wenige Mechanismen zur Erfassung von API-Leistung und -Sicherheit gibt, könnten Teams Schwierigkeiten haben, die Kontrolle über das Ökosystem zu behalten. Zum Beispiel könnte ein Unternehmen nichts von Sicherheitsverletzungen, Versionsfehlern oder Authentifizierungsproblemen innerhalb eines bestimmten Clusters wissen.

Managed Frameworks nutzen Telemetriedaten, KPIs und andere Kennzahlen, um die API-Leistung detaillierter zu erfassen. Ein Überwachungssystem kann beispielsweise Entwickler warnen, wenn Clients mit übermäßigen API-Stillständen konfrontiert sind, und helfen, das zugrunde liegende Problem zu identifizieren – sei es Serverüberlastung, Netzwerkausfälle, Codefehler oder ein anderes Problem.

Verwaltete Ökosysteme verfügen möglicherweise auch über eine fortschrittlichere API-Governance-Infrastruktur, die die Teamautonomie bewahrt und den Stakeholdern ein klares Verständnis darüber gibt, für welche APIs sie verantwortlich sind. Schließlich führen verwaltete Ökosysteme formale Lebenszyklusmanagementprozesse ein, bei denen APIs über Design, Entwicklung, Wartung, Versionierung und Außerbetriebnahme hinweg überwacht werden. Auf dieser Ebene fehlt es Unternehmen jedoch möglicherweise noch an einer zusammenhängenden Vorstellung davon, wie das API-Management zu den übergeordneten Geschäftszielen beiträgt.

Optimierte oder strategische Frameworks kombinieren Governance, Standardisierung, Lebenszyklusmanagement, Metriken und Best Practices mit langfristiger Geschäftsplanung. Mit der Aufsicht über das gesamte Netzwerk können Unternehmen effizient skalieren und Ressourcen zuweisen und dynamisch auf sich ändernde Marktbedingungen reagieren. Anstatt APIs nur als technische Komponenten zu betrachten, können Unternehmen APIs im Dienst breiterer Geschäftsziele bereitstellen. Strategische Frameworks helfen Unternehmen dabei, zukunftsorientierte Roadmaps und Strategien zu entwickeln, Innovation zu beschleunigen und die operative Effizienz zu verbessern.

Unternehmen könnten API-Reifegradmodelle erstellen, um bestimmte Problembereiche oder betriebliche Schwerpunkte anzusprechen. Zu den gemeinsamen Schwerpunkten gehören:

Diese Reifemodelle konzentrieren sich auf API-Designprinzipien, wie die Einführung spezifischer Protokolle, Praktiken und Standards, die zu einer verbesserten Benutzererfahrung beitragen. Das RMM ist ein Beispiel für ein designbasiertes Framework, andere Modelle konzentrieren sich hingegen auf GraphQL, gRPC und andere Architekturstile.

Governance-Modelle konzentrieren sich darauf, inwieweit Unternehmen die Kontrolle und Aufsicht über ihre API-Ökosysteme behalten können. Auf den höchsten Ebenen gewährleisten Unternehmen ein hohes Maß an Compliance, Datenqualität und -sicherheit bei gleichzeitiger Wahrung der Autonomie der Stakeholder.

Governance-basierte Frameworks berücksichtigen auch die Qualität der Durchsetzungsmechanismen eines API-Ökosystems, einschließlich der Frage, ob es automatische Prüfungen und Validierungsprozesse integriert. Eigentümermodelle hingegen weisen APIs bestimmten Teams zu, sodass jede API berücksichtigt wird.

Sicherheitsorientierte Frameworks bewerten die Einhaltung von Best Practices durch ein API-Netzwerk. In den frühesten Phasen können Organisationen auf API-Schlüssel oder einfache HTTP-Authentifizierung setzen, die sowohl keine granulare Kontrolle haben als auch anfällig für Exposition sind. Fortschrittliche Systeme könnten Token-basierte Authentifizierung und Autorisierung sowie Zero-Trust-Zugriff einführen. Die ausgefeiltesten Frameworks halten sich an Identity und Access Management (IAM)-Prinzipien, wie die Verwendung der OAuth- und OpenID Connect (OIDC)-Autorisierungsprotokolle.

API-Dokumente sind technische Leitfäden, die Anweisungen zur Verwendung und Integration einer bestimmten API durch Entwickler enthalten. Die Dokumentation kann Tutorials und Codebeispiele sowie Release Notes und akzeptable Aufrufparameter enthalten.

Anfangs verfügen Unternehmen möglicherweise über keinen standardisierten Prozess zur Erstellung und Pflege der API-Dokumentation, sodass Entwickler nur wenig Einblick in die Möglichkeiten der einzelnen APIs erhalten. Höhere Ebenen könnten standardisierte Formate zur Beschreibung von API-Spezifikationen einführen, wie beispielsweise die OpenAPI Specification (OAS) oder den API Blueprint. Ausgereifte API-Frameworks könnten auch Automatisierung integrieren, um sicherzustellen, dass die Dokumentation automatisch bei jedem Rollout aktualisiert wird.

Observability-fokussierte Reifegradmodelle helfen Unternehmen dabei, die Komplexität ihrer Datenerfassungsmechanismen über Microservices hinweg zu verfolgen. Grundlegende Systeme können Telemetrie und Metriken nutzen, um Unternehmen bei der Fehlererkennung zu unterstützen, sind jedoch nicht in der Lage, langfristige Datentrends zu identifizieren.

Komplexere Plattformen können Latenz, Anfrageraten und andere relevante Kennzahlen proaktiv verfolgen, um Unternehmen bei Ausfallzeiten, Fehlanpassungen und anderen Problemen im Voraus zu helfen. In der höchsten Ebene können Unternehmen allgemeine Datenmuster identifizieren und umsetzbare Erkenntnisse gewinnen, die als Leitfaden für die zukünftige API-Entwicklung dienen.