Wie sieht der API-Lebenszyklus aus?

APIs sind Regeln oder Protokolle, die es Anwendungen ermöglichen, miteinander zu kommunizieren, um Daten, Funktionen und Funktionalität auszutauschen. Es gibt sowohl einen API-Produzenten-Lebenszyklus – der sich auf die Erstellung und Verbreitung von APIs konzentriert – als auch einen API-Konsumenten-Lebenszyklus, der sich auf die API-Nutzung aus Sicht des Verbrauchers konzentriert. Dieser Artikel konzentriert sich auf den Lebenszyklus von API-Produzenten.

Es gibt keinen universellen Lebenszyklus für API-Produzenten. Je nach Quelle können unterschiedliche Varianten auftreten, aber der Lebenszyklus umfasst im Allgemeinen die folgenden Phasen: Planung, Entwurf, Entwicklung, Test, Bereitstellung, Überwachung und Außerbetriebnahme.

API-Management-Plattformen werden häufig verwendet, um den gesamten API-Lebenszyklus zu organisieren und um die API-Strategie, Verwaltung, Dokumentation und Verzeichnisse in einer IT-Umgebung zu zentralisieren. Viele Plattformen verfügen über erweiterte Analysefunktionen und Tools für die API-Erkennung und Monetarisierung, die Unternehmen dabei helfen, das Beste aus ihren APIs herauszuholen.

Die Berücksichtigung und das Verständnis des gesamten API-Lebenszyklus helfen den Entwicklungsteams, Ressourcen effizienter zuzuweisen, realistische Zeitpläne für die Bereitstellung zu erstellen, alle Stakeholder während des gesamten Prozesses zu informieren und sicherzustellen, dass APIs den Geschäftsanforderungen entsprechen. Im Wesentlichen trägt ein gut durchdachter und umgesetzter Lebenszyklus dazu bei, leistungsstarke und sichere APIs sowie ein besseres Benutzererfahrung zu liefern.

Das durchgängige API-Lifecycle-Management umfasst mehrere wichtige Phasen, angefangen mit der Vorplanung und endet, oft, aber nicht immer, mit der Außerbetriebnahme oder dem Ersatz. Als Beispiel nehmen wir ein Softwareunternehmen, das beschließt, eine API zu entwickeln, um seine Kundendaten mit Geschäftstools wie Support-Ticketing, Buchhaltungssystemen, Projektmanagementplattformen und mehr zu synchronisieren.

Die Entwicklung einer API beginnt mit der Beantwortung einiger grundlegender Fragen: Warum wird diese API benötigt, für wen ist sie gedacht, wie wird sie eingesetzt und wie wird der Erfolg gemessen? 

Wenn Sie das Ziel des API-Projekts genau angeben, können Sie klären, welche Merkmale und Funktionen das API-Design haben muss. Im Beispiel der Softwareentwicklung besteht das Ziel der API darin, sicherzustellen, dass Kundendaten nahtlos zwischen Anwendungen und Plattformen, die das Unternehmen verwendet oder einsetzen möchte, verschoben werden können. 

In dieser Planungsphase haben Unternehmen:

• Prüfen Sie die potenziellen geschäftlichen Vorteile der API.
• Beschreiben Sie, wie diese API die Geschäftsanforderungen erfüllt.
• Stellen Sie sicher, dass es keine bestehenden APIs oder andere verfügbare Produkte auf nativen Integrationsmarktplätzen gibt, die die erforderlichen Funktionen bieten (im Wesentlichen bestätigen Sie, dass die Entwicklung dieser API notwendig ist).
• Legen Sie klar dar, welche Anwendungen und Plattformen auf die API angewiesen sein werden und wie die API in bestehende Workflows integriert wird.

Anschließend sollte das Team potenzielle Nutzer und Anwendungsfälle besprechen. Ist das ausschließlich für den internen Gebrauch bestimmt? Welche Teams werden diese API nutzen und wofür? Gibt es Sicherheitsbedenken, die in der Design- und Entwicklungsphase berücksichtigt werden sollten? Und ganz entscheidend: Wer wird für jede Phase der API-Produktion verantwortlich sein?

Die Festlegung eines Zeitplans für den Abschluss des Projekts hilft sicherzustellen, dass das Projekt innerhalb des Budgets bleibt. Wichtig ist, dass die Zeitpläne realistisch und flexibel sind. 

Die Teams beantworten Fragen wie: Gibt es bestimmte Termine, wie zum Beispiel ein Startdatum für neue Funktionen, die eingehalten werden müssen? Gibt es Sicherheits- oder Rechtsabteilungen oder andere Beteiligte, die vor der Bereitstellung dieser API ihre Zustimmung erteilen müssen? 

Wo werden Dokumentationen und andere Informationen zur API gespeichert und Entwicklern und Nutzern gleichermaßen zugänglich gemacht? Wo werden Codeänderungen verfolgt und gespeichert?

Die Beantwortung solcher Fragen zu Beginn hilft, einen klaren Plan für den restlichen Lebenszyklus zu erstellen.

Während in der Planungsphase das gewünschte Ergebnis beschrieben wird, definiert die Entwurfsphase, wie das Team dieses Ergebnis erreichen will. Während des gesamten Designprozesses entscheidet das API-Designteam, wie die API erstellt werden soll, um die in der Planungsphase detaillierten Anforderungen zu erfüllen. 

Das Team muss Designentscheidungen bezüglich des Protokolls und des Architekturstils treffen, den die API verwenden wird. Diese Entscheidung könnte auf der bestehenden API-Architektur des Unternehmens oder auf den beabsichtigten Anwendungsfällen für diese neue API basieren.

Zu den gängigen API-Frameworks und Architekturen gehören beispielsweise REST, GraphQL und gRPC; jedes hat seine eigenen Stärken und Schwächen. 

• REST: Einfach, intuitiv und weit verbreitet, aber nicht ideal für komplexe Abfragen und bietet keine starke Typisierung.
  
  
• GraphQL: Effizient, mit starker Typisierung und integrierter Dokumentation. GraphQL kann aber auch komplex sein und mehr Einrichtung und spezifisches Fachwissen erfordern als REST.
  
  
• gRPC: Schnell, mit starker Eingabe, automatischer Codegenerierung und bidirektionalem Streaming. gRPC wird häufig für Mikroservices-Kommunikation verwendet. Da es sich jedoch um ein neueres Framework handelt, kann es eine gewisse Einarbeitungszeit geben, und die Dokumentation ist binär und nicht für Menschen lesbar. 

Beim Design der API entscheidet das Team außerdem, welche Art der Authentifizierung geeignet ist (wie etwa OAuth 2.0) und ob die API hinter einem API-Gateway sitzen soll.

Ein Spezifikationsdokument beschreibt die Struktur, das Verhalten und die Funktionalität einer API auf standardisierte Weise. Es bietet eine einzige Informationsquelle mit Informationen darüber, wie die API aufgebaut ist, was sie kann und wie man damit interagiert. 

Die beliebteste standardisierte Spezifikation ist die OpenAPI-Spezifikation, die es Entwicklern ermöglicht, Pfade, Methoden, Parameter, Authentifizierungsmethoden und mehr zu definieren. OpenAPI wird speziell für REST-APIs verwendet und unterstützt eine Reihe von Open-Source-Tools namens Swagger, die Codegenerierung, Bearbeitung und automatische Erstellung von Dokumentationen ermöglichen.

Für GraphQL ist die äquivalente Spezifikation das GraphQL-Schema, ein stark typisierter Vertrag, der in Schema-Definitionssprache geschrieben ist, oder SDL, ein menschenlesbares Format. Das GraphQL-Ökosystem bietet einige verschiedene Tools, die dieses Schema auf eine Art und Weise nutzen, die ähnliche Funktionen wie OpenAPI bietet. GraphiQL ist beispielsweise ein in den Browser integriertes Entwicklungs-Ökosystem (IDE), das Entwicklern als Sandbox dient. 

Bei gRPC ist Protocol Buffers, oder protobuf, ein Serialisierungsformat und eine Schnittstellendefinitionssprache (IDL), die als das am häufigsten verwendete Dateiformat für Spezifikationen dient. Protobuf bietet kein interaktives Testen an, obwohl es Web-UIs gibt, die dies ermöglichen. 

In dieser Phase beginnen die Entwickler mit der Codierung und folgen dabei dem im vorherigen Schritt skizzierten API-Designplan. Ein Versionskontrollsystem dient dazu, Versionen und Codeänderungen während des gesamten Entwicklungsprozesses zu verfolgen.

Der Industriestandard für Versionskontrollsysteme ist Git, eine Open-Source-Software, die Änderungen im lokal auf dem Gerät eines Entwicklers gespeicherten Code verfolgt. Entwickler nutzen Git, um ihren Code zu erstellen, zu verwalten und Änderungen daran nachzuverfolgen, benötigen dann aber einen Ort, an dem dieser für sie selbst und andere zugänglich ist. 

GitHub ist der beliebteste Git-Hosting-Dienst, der sowohl kostenlose als auch kostenpflichtige Varianten anbietet und die Speicherung, den Abruf und die Zusammenarbeit von Git-Code-Repositories ermöglicht. Es gibt Alternativen für das Hosting von Git-Repositories, darunter GitLab, AWS CodeCommit und Microsoft Azure Repos.

API-Tests werden sowohl während als auch nach der API-Entwicklung durchgeführt; Kontinuierliches Testen unterstützt die Entwicklung, indem es Schwachstellen und Bedürfnisse aufdeckt und regelmäßige Updates ermöglicht. 

Beim Unit-Testing werden kleine Teile des Codes isoliert und einzeln getestet. Nehmen wir als Beispiel die API unseres Softwareunternehmens. Das Team muss die Antwort auf eine Anfrage zum Abrufen von Benutzerinformationen testen. Der GET-Befehl dient dazu, den Namen und die E-Mail-Adresse eines Benutzers aus der ID-Nummer dieses Benutzers in einer Kundendatenbank abzurufen. Unit-Testing beinhaltet die Sicherstellung, dass diese GET-Anfrage die beabsichtigten Informationen abruft und eine Anfrage nach einer nicht vorhandenen Benutzer-ID eine entsprechende Fehlermeldung zurückgibt.

Integrationstests werden in der Regel nach Unit-Tests durchgeführt und dienen dazu, Probleme zu erkennen, die Unit-Tests übersehen. Mit Integration Testing kann sichergestellt werden, dass mehrere Komponenten oder Services wie vorgesehen über die API kommunizieren können. 

Zurück zu unserem Beispiel. Nehmen wir an, eine Funktion der API ist, dass ein Webhook oder eine Benachrichtigung von einem System zum anderen gesendet wird, falls ein bestimmtes Ereignis eintritt, wie zum Beispiel die Aufnahme eines neuen Kunden. Um sicherzustellen, dass dies funktioniert, wird ein Integration mit einem gefälschten Server eingerichtet, der eine Benachrichtigung erhält und die erwartete Aktion ausführt, wenn die Informationen eines neuen Kunden zum CRM hinzugefügt werden. Dieser Prozess wird bei allen Integrationen wiederholt.

API-Vertragstests stellen sicher, dass eine API das tut, was die Benutzer erwarten. Der Vertrag wird typischerweise als OpenAPI-Spezifikationsdatei erstellt. Dabei handelt es sich um ein standardisiertes, maschinenlesbares Dokument, das die Elemente der Funktionalität und der Funktionen einer API beschreibt. Eine API-Spezifikationsdatei wird typischerweise in JSON oder YAML geschrieben und enthält Elemente wie API-Endpunkte, Authentifizierungsmethoden, die spezifischen Formate akzeptabler Anfragen und Antworten, Metadaten und Eingabeparameter.

Die Bewertung der API-Leistung umfasst üblicherweise die Bewertung ihrer Geschwindigkeit und Effizienz. In dieser Phase messen Tester die Antwortzeit der Abfrage, Fehlerraten, Ressourcenverbrauch (wie CPU- und Speicherverbrauch), Latenz und Durchsatz. Wenn Sie die Leistung einer API in dieser Phase verstehen, können Sie Engpässe oder Redundanzen erkennen, die das Benutzererlebnis verlangsamen können.

APIs werden häufig zur Übertragung sensibler Daten verwendet, daher sind Sicherheitstests eine wichtige Komponente. API-Sicherheitstests versuchen im Wesentlichen, die API auf verschiedene Weise zu knacken, um die API-Sicherheit und Stabilität zu gewährleisten. Diese Versuche könnten Eingabevalidierungstests beinhalten, um sicherzustellen, dass Daten nur akzeptiert werden, wenn sie in vorab genehmigten Formaten eingegeben werden. 

Beim Input-Validierungstest wird nach verschiedenen Arten von Angriffen gesucht. Zu den häufigsten Arten von Angriffen gehört die SQL-Injektion, bei der böswillige Akteure bösartigen Code in eine Anwendung einfügen. SQL ist eine Sprache, die zur Kommunikation mit Datenbanken verwendet wird, und bestimmte universelle SQL-Befehle können unbefugte Antworten auslösen, wie etwa eine Liste aller Benutzer. 

Zu den weiteren Sicherheitsprüfungsmethoden gehören Authentifizierungstests, die sicherstellen, dass Identifizierungssicherheitsmaßnahmen wie biometrische Daten ordnungsgemäß funktionieren, und Autorisierungstests, die sicherstellen, dass Benutzer nur auf die Funktionen zugreifen können, für deren Zugriff sie genehmigt wurden. 

Sicherheitstests werden sowohl während als auch nach der Entwicklungsphase durchgeführt, und neue Funktionen der künstlichen Intelligenz (KI) und die Automatisierung verbessern die Stärke und Genauigkeit dieser Tests. KI-Sicherheitstest-Tools können automatisch Tests erstellen, Code auf Fehler scannen, Leistung analysieren, um Probleme vorherzusagen und anomales Verhalten zu markieren, und vieles mehr.

In Branchen wie dem Gesundheitswesen und den Finanzdienstleistungen gibt es Vorschriften, Gesetze und Richtlinien zum Schutz der Sicherheit und der Privatsphäre der Nutzer. Beispiele hierfür sind HIPAA (amerikanische Gesundheitsdatenschutzbestimmungen), DSGVO (EU-Datenschutzbestimmungen) und CCPA (kalifornische Datenschutzbestimmungen). 

Compliance-Tests sind Tests, die sicherstellen, dass die API allen geltenden Gesetzen und Richtlinien entspricht. Die DSGVO gewährt beispielsweise das „Recht auf Vergessenwerden“, was bedeutet, dass Nutzer die vollständige Löschung ihrer Daten ohne unangemessene Verzögerung verlangen können. Bei Compliance-Tests für eine DSGVO-konforme API muss sichergestellt werden, dass diese Regel eingehalten wird.

Die Bereitstellungsphase ist der Start der API. Es wurde auf Funktionalität, Sicherheit und Compliance getestet und ist einsatzbereit. In der Bereitstellungsphase wechselt die API von der Testumgebung in die Live-Produktionsumgebung. Die Bereitstellung von APIs umfasst mehrere Schritte.

Vor der Bereitstellung sollte das Team eine weitere Überprüfung durchführen, um sicherzustellen, dass die unterstützende Infrastruktur, API-Dokumentation, Benutzerunterstützung, Vertriebs- und Kommunikationsstrategien sowie Überwachungsprotokolle vollständig abgeschlossen und einsatzbereit sind. Diese Checkliste könnte unter anderem Folgendes umfassen: Skalierung von Servern, Konfiguration von Alerts and Notification, Erstellung einer FAQ-Seite, Versand einer Mitteilung an Kunden (oder einer öffentlichen Mitteilung) und vieles mehr.

CI/CD, was für Continuous Integration/Continuous Bereitstellung steht, umfasst eine Reihe von Verfahren, die Softwareentwicklungs-, Test- und Bereitstellungszyklen automatisieren und optimieren. Es ist eine grundlegende Praxis innerhalb der DevOps-Methodik. Wie Softwareanwendungen werden auch APIs häufig in CI/CD-Pipelines integriert, um die Bereitstellung, das Testen und die Aktualisierung von APIs zu optimieren und zu automatisieren. 

Ein API Gateway ist eine Softwareebene, die Clients einen einzigen Einstiegspunkt für den Zugriff auf eine Vielzahl von Backend-Services oder mehrere Instanzen eines Backend-Services bietet. API-Gateways bieten mehrere Vorteile:

• Einfachheit: Kunden müssen nur eine einzige Service-URL im Auge behalten und nicht viele
  
  
• Lastausgleich: Ein Unternehmen kann den Datenverkehr für einen einzelnen Dienst auf mehrere Instanzen verteilen, um die Last zu verteilen und Leistungsengpässe zu vermeiden.
  
  
• Sicherheit und Governance: Ein Gateway kann verwendet werden, um standardisierte Sicherheits- und Governance-Protokolle über viele APIs hinweg anzuwenden. 
  
  
• Caching: Ein Gateway kann beim Caching helfen, indem es häufig abgerufene Daten über mehrere Dienste hinweg speichert. Das hilft, Antworten zu beschleunigen und die Leistung zu verbessern.

Organisationen veröffentlichen häufig Beta-Versionen für ausgewählte Benutzer, um eine API zu testen, bevor sie diese vollständig für die Öffentlichkeit freigeben. So kann das Unternehmen Fehler finden und beheben, Feedback einholen, die Leistung messen und die API in einer sichereren, besser kontrollierten Umgebung bewerben.

Sobald die Checkliste abgearbeitet und alle Beta-Tests abgeschlossen sind, ist es an der Zeit, „den Schalter umzulegen“ und die API vollständig zu implementieren. Dieser Prozess könnte die Einführung von Vertriebsstrategien beinhalten, um interne oder externe Kunden über die API zu informieren und ihre Nutzung zu fördern. Der Verteilungsprozess kann auch die Veröffentlichung von Benutzerhandbüchern und anderen öffentlichen Maßnahmen umfassen, eine Website oder ein API-Verzeichnis aktualisieren und die Einstellungen so anpassen, dass der sofortige Zugriff möglich ist, anstatt eine private Authentifizierung zu verlangen.

Einer der wichtigsten Vorteile, den das Verständnis und die Planung eines kompletten API-Lebenszyklus mit sich bringt, ist die Gewährleistung, dass Monitoring, Observability und Wartung von Anfang an im Fokus stehen. Die Arbeit ist beim Start noch nicht abgeschlossen; es gibt noch viel zu tun. API-Überwachung ist ein fortlaufender Prozess, der darauf ausgelegt ist, zu sehen, wie eine API in der realen Welt in Echtzeit funktioniert. 

Zu den wichtigsten Metriken für die Überwachung gehören die Antwortzeit, also wie lange die API benötigt, um auf Anfragen zu reagieren; die Fehlerrate, also der Prozentsatz der Anfragen, die fehlschlagen; der Durchsatz und der Datenverkehr, also die Anzahl der Anfragen, die die API verarbeiten kann; und die Infrastrukturanalyse, die die Belastung und den Zustand der Server misst.

Der Wartungsaspekt besteht in der Reaktion auf die von den Überwachungsinstrumenten erfassten Daten. Die Wartung kann in Form von Bugfixes, Leistungsoptimierung oder sogar dem Hinzufügen neuer Funktionen oder Fähigkeiten erfolgen.

In unserem CRM-Beispiel könnten Überwachungstools feststellen, dass die Latenz hoch ist, wenn Kundendaten von einer Plattform zur anderen gesendet werden; die Wartung kann dem entgegenwirken, indem Code-Redundanzen reduziert, Caching-Einstellungen feinabgestimmt oder Server näher an die Kunden verlegt werden, die sie bedienen.

Das Ende des Lebenszyklus einer API ist genauso wichtig, dynamisch und aufschlussreich wie jede andere Phase.

Versionierung ist der erweiterte Prozess der Aufrechterhaltung der Wirksamkeit einer API durch Aktualisierungen während ihrer gesamten aktiven Lebensdauer. Der Schlüssel zur Versionsführung besteht darin, Änderungen und Verbesserungen anzubieten, ohne bestehende Funktionen für etablierte Nutzer zu zerstören. 

Bei einfachen Fixes und ähnlichem werden Updates in der Regel ohne Veröffentlichung einer neuen API-Version herausgegeben, da diese kleinen Änderungen als „nicht inkompatible Änderungen“ gelten. Aber bei „bahnbrechenden“ Änderungen, bei denen eine neue Version nicht abwärtskompatibel mit der Version ist, die sie ersetzen soll, ist es eine gute Praxis, die Änderung als neue Version einzuführen.

Kommunikation, sowohl frühzeitig als auch häufig, ist der Schlüssel zur Versionierung. Eine gängige Praxis ist die Unterstützung paralleler Versionen: Die ältere Version bleibt zusammen mit der neuen Version aktiv und funktionsfähig, und Entwickler kommunizieren Änderungen, um Nutzer zur Migration zur neuen Version zu bewegen. Sobald alle oder genug Nutzer migriert sind, kann die alte Version deaktiviert werden.

Die Außerbetriebnahme einer API bedeutet deren dauerhafte Entfernung und Deaktivierung. Nicht alle APIs werden eingestellt, aber es ist üblich, eine API irgendwann zu ersetzen. Es gibt mehrere Gründe, warum eine API stillgelegt werden könnte:

• Die Leistung einer neuen Version übertrifft die alte
• Compliance- oder Sicherheitsbedürfnisse werden nicht mehr ausreichend berücksichtigt 
• Geschäfts- oder finanzielle Veränderungen innerhalb des Unternehmens
• Inkompatibilität mit neuerer Software

Nach der Einstellung ist eine API nicht mehr funktionsfähig. Es gibt jedoch einige Schritte, die diesen Übergang erleichtern können.

Die Abschaltung einer API erfordert Diskussionen. Ist es notwendig, die API abzuschalten, und warum? Welche Alternative gibt es gegebenenfalls? Wer muss über den bevorstehenden Ruhestand informiert werden?

Üblicherweise kündigt die Organisation an, dass eine API außer Betrieb genommen wird. Diese Ankündigung enthält alle notwendigen Informationen für Nutzer der API, wie zum Beispiel, warum diese Änderung stattfindet, wann sie stattfinden wird und welche Maßnahmen der Nutzer gegebenenfalls ergreifen muss. 

Dann ist die API offiziell veraltet. Die API ist zum jetzigen Zeitpunkt weiterhin funktionsfähig, erhält aber keine neuen Updates oder Funktionen mehr. Der Zeitraum für die Abschaffung ist so konzipiert, dass der Benutzer Zeit hat und weiß, dass die notwendigen Anpassungen vorgenommen werden müssen.

Der „Sunset Day“ ist der Tag, an dem die öffentliche API vollständig abgeschaltet wird. Ab diesem Zeitpunkt werden keine Anfragen mehr beantwortet und Clients, die versuchen, die API zu erreichen, erhalten eine Fehlermeldung. Es empfiehlt sich, die Dokumentation entsprechend zu aktualisieren und jeglichen Serverplatz oder sonstige Infrastruktur, die von der API genutzt wurde, freizugeben. 

Eine Obduktion einer veralteten API kann sich als nützlich erweisen. Teams können die im Laufe des gesamten API-Lebenszyklus gewonnenen Erkenntnisse diskutieren und darüber sprechen, wie diese auf zukünftige Projekte angewendet werden können.