Die Vorteile eines API-First-Ansatzes bei der Entwicklung von Microservices

NGINX | 19. Januar 2023

APIs sind das verbindende Element cloudnativer Anwendungen – über sie kommunizieren die einzelnen Microservices einer Anwendung miteinander. Mit dem Wachstum und der Skalierung von Anwendungen nimmt auch die Anzahl der Microservices und APIs zu. Obwohl dies in den meisten Fällen unvermeidlich ist, stellt es die Platform-Ops-Teams, die für die Zuverlässigkeit, Skalierbarkeit und Sicherheit moderner Anwendungen verantwortlich sind, vor erhebliche Herausforderungen. Wir bezeichnen dieses Problem als API-Wildwuchs und haben bereits in einem früheren Blogbeitrag darüber geschrieben.

Als ersten Versuch, die unkontrollierte Ausbreitung von APIs einzudämmen, könnte ein Unternehmen einen Top-down-Ansatz verfolgen und Tools zur automatisierten Erkennung und Fehlerbehebung von APIs implementieren. Dies ist zwar kurzfristig effektiv, stellt jedoch häufig eine unverhältnismäßige Belastung für die Teams dar, die für die Entwicklung und den Betrieb von APIs und Microservices verantwortlich sind. Sie müssen entweder bestehende Microservices und APIs überarbeiten, um Sicherheits- und Compliance-Probleme zu beheben, oder ein aufwendiges Prüfverfahren durchlaufen, um die erforderlichen Genehmigungen zu erhalten. Aus diesem Grund verfolgen viele große Softwareunternehmen einen dezentralen Ansatz, der mithilfe adaptiver Governance den Entwicklern die benötigte Autonomie gewährt.

Anstatt in letzter Minute Schutzmaßnahmen zu ergreifen, ist ein Bottom-up-Ansatz zur Lösung des Problems langfristig effektiver. Dabei werden zunächst die Teams einbezogen, die APIs für verschiedene Microservices und Anwendungen entwickeln und betreiben. Häufig beginnen sie damit, einen API-First-Ansatz für die Softwareentwicklung in Ihrem Unternehmen einzuführen.

Was bedeutet API-First?

APIs gibt es bereits seit Jahrzehnten. Doch sie sind längst nicht mehr nur „Programmierschnittstellen für Anwendungen“. Im Kern sind APIs Schnittstellen für Entwickler. Wie jede Benutzeroberfläche müssen auch APIs geplant, gestaltet und getestet werden. Beim API-First-Ansatz geht es darum, die Bedeutung von Konnektivität und Einfachheit für alle Teams, die APIs betreiben und nutzen, anzuerkennen und in den Vordergrund zu stellen. Dabei haben Kommunikation, Wiederverwendbarkeit und Funktionalität für API-Nutzer, bei denen es sich fast immer um Entwickler handelt, höchste Priorität.

Es gibt viele Wege zu API‑first, doch für die meisten Unternehmen, die sich auf den Weg zu API‑first machen, ist ein designorientierter Ansatz bei der Softwareentwicklung das letztendliche Ziel. In der Praxis bedeutet dieser Ansatz, dass APIs vor der Implementierung vollständig definiert werden. Die Arbeit beginnt mit dem Entwurf und der Dokumentation der Funktionsweise der API. Das Team stützt sich auf das daraus resultierende Artefakt, das häufig als API‑Vertrag bezeichnet wird, um daraus abzuleiten, wie die Funktionalität der Anwendung implementiert werden soll.

Entdecken Sie in Kapitel 1 des E-Books Mastering API Architecture von O’Reilly, das Ihnen von NGINX kostenlos zur Verfügung gestellt wird, Designtechniken für einen dauerhaften und flexiblen API-First-Ansatz bei der Softwareentwicklung.

Der Nutzen von API-First für Unternehmen

Eine API-First-Strategie eignet sich häufig ideal für Microservices-Architekturen, da sie sicherstellt, dass Anwendungsökosysteme von Anfang an modular und wiederverwendbar aufgebaut sind. Die Einführung eines API-First-Modells für die Softwareentwicklung bietet sowohl Entwicklern als auch Unternehmen erhebliche Vorteile, darunter:

Höhere Entwicklerproduktivität – Entwicklungsteams können parallel arbeiten und Backend-Anwendungen aktualisieren, ohne die Teams zu beeinträchtigen, die an anderen, von den APIs dieser Anwendungen abhängigen Microservices arbeiten. Die Zusammenarbeit über den gesamten API-Lebenszyklus hinweg gestaltet sich häufig einfacher, da sich jedes Team auf den festgelegten API-Vertrag beziehen kann.
Verbesserte Entwicklererfahrung – Beim API-First-Design steht die Entwicklererfahrung im Vordergrund, indem sichergestellt wird, dass eine API logisch aufgebaut und gut dokumentiert ist. So können Entwickler reibungslos mit einer API interagieren. Erfahren Sie, warum es für Platform-Ops-Teams so wichtig ist, die API-Entwicklererfahrung zu berücksichtigen<.htmla>.
Einheitliche Governance und Sicherheit – Cloud- und Plattformarchitekten können das API-Ökosystem einheitlich organisieren, indem sie bereits in der API-Designphase Sicherheits- und Governance-Regeln berücksichtigen. Dadurch lassen sich kostspielige Überprüfungen vermeiden, die erforderlich werden, wenn Probleme erst später im Softwareentwicklungsprozess entdeckt werden.
Verbesserte Softwarequalität – Durch den API-First-Ansatz wird sichergestellt, dass Sicherheits- und Compliance-Anforderungen bereits frühzeitig im Entwicklungsprozess erfüllt werden, lange bevor die API für die Bereitstellung in der Produktionsumgebung bereit ist. Da Sicherheitslücken seltener in der Produktionsumgebung behoben werden müssen, haben Ihre Teams für Betrieb, Qualitätssicherung und Sicherheit mehr Zeit, direkt mit den Entwicklungsteams zusammenzuarbeiten und sicherzustellen, dass Qualitäts- und Sicherheitsstandards bereits in der Entwurfsphase eingehalten werden.
Schnellere Markteinführung – Dank weniger Abhängigkeiten und eines einheitlichen Frameworks für die Kommunikation zwischen Diensten können verschiedene Teams ihre Dienste wesentlich effizienter entwickeln und verbessern. Eine einheitliche, maschinenlesbare API-Spezifikation kann dazu beitragen, dass Entwickler und Platform-Ops-Teams besser zusammenarbeiten können.

Insgesamt kann die Einführung eines API-First-Ansatzes einem Unternehmen dabei helfen, eine flexiblere, skalierbarere und sicherere Microservices-Architektur aufzubauen.

Wie die Einführung einer gemeinsamen API-Spezifikation helfen kann

In einer typischen Microservice- und API-Landschaft eines Unternehmens sind mehr Komponenten im Einsatz, als ein Platform-Ops-Team im Tagesgeschäft im Blick behalten kann. Die Einführung und Nutzung einer standardisierten, maschinenlesbaren API-Spezifikation hilft Teams dabei, die derzeit in ihren Umgebungen betriebenen APIs zu verstehen, zu überwachen und fundierte Entscheidungen darüber zu treffen.

Die Einführung einer einheitlichen API-Spezifikation kann auch dazu beitragen, die Zusammenarbeit mit Stakeholdern während der API-Designphase zu verbessern. Indem Sie einen API-Vertrag erstellen und diesen in einer Standardspezifikation formalisieren, können Sie sicherstellen, dass alle Stakeholder ein gemeinsames Verständnis davon haben, wie eine API funktionieren wird. Außerdem lassen sich wiederverwendbare Definitionen und Funktionen leichter teamübergreifend nutzen.

Heute gibt es drei gängige API-Spezifikationen, die jeweils die meisten API-Typen unterstützen:

OpenAPI – JSON- oder YAML-Beschreibungen aller Web-APIs und Webhooks
AsyncAPI – JSON- oder YAML-Beschreibungen ereignisgesteuerter APIs
JSON Schema – JSON-Beschreibungen der für APIs verwendeten Schemaobjekte

REST-APIs machen heute den Großteil der produktiv eingesetzten APIs aus, und die OpenAPI-Spezifikation ist der Standard für die Definition einer REST-API. Sie stellt einen maschinenlesbaren Vertrag bereit, der die Funktionsweise einer bestimmten API beschreibt. Die OpenAPI-Spezifikation wird von zahlreichen Tools für das API-Management und API-Gateways unterstützt, darunter auch NGINX. Im weiteren Verlauf dieses Blogbeitrags geht es darum, wie Sie mithilfe der OpenAPI-Spezifikation einige wichtige Anwendungsfälle umsetzen können.

Die OpenAPI-Spezifikation ist ein Open-Source-Format zur Definition von APIs in JSON oder YAML. Sie können darin zahlreiche API-Eigenschaften festlegen, wie das folgende einfache API-Beispiel zeigt. Hier gibt eine einfache HTTP-GET-Anfrage eine Liste von Artikeln auf einer fiktiven Einkaufsliste zurück.

openapi: 3.0.0info:
  version: 1.0.0
  title: Grocery List API
  description: An example API to illustrate the OpenAPI Specification

servers:
url: https://api.example.io/v1

paths:
  /list:
    get:
      description: Returns a list of stuff on your grocery list             
      responses:
        '200':
          description: Successfully returned a list
          content:
            schema:
              type: array
              items:
                type: object
                properties:
                   item_name:
                      type: string

Definitionen, die der OpenAPI-Spezifikation entsprechen, sind sowohl für Menschen als auch für Maschinen lesbar. Somit gibt es eine zentrale Informationsquelle, die die Funktionsweise jeder API dokumentiert. Dies ist besonders wichtig für Organisationen, in denen viele Teams APIs entwickeln und betreiben. Um APIs in großem Umfang zu verwalten, zu steuern und abzusichern, müssen Sie natürlich sicherstellen, dass auch die übrigen Tools Ihrer API-Plattform – API-Gateways, Entwicklerportale und erweiterte Sicherheitslösungen – die OpenAPI-Spezifikation unterstützen.

Erfahren Sie in Kapitel 1 von „Mastering API Architecture“ mehr darüber, wie Sie REST-APIs mithilfe der OpenAPI-Spezifikation entwerfen.

Vorteile der Einführung einer einheitlichen API-Spezifikation

Die Verwendung einer einheitlichen API-Spezifikation wie der OpenAPI-Spezifikation bietet mehrere Vorteile:

Verbesserte Interoperabilität – Eine einheitliche, maschinenlesbare Spezifikation ermöglicht es verschiedenen Systemen und Clients, den API-Vertrag zu verarbeiten und zu nutzen. Dadurch können Platform-Ops-Teams komplexe Architekturen leichter integrieren, verwalten und überwachen.
Einheitliche Dokumentation – Der API-Vertrag wird in einem Standardformat dokumentiert, einschließlich der Endpunkte, Anfrage- und Antwortformate sowie weiterer relevanter Details. Viele Systeme können den Vertrag nutzen, um eine umfassende Dokumentation zu erstellen. Dies sorgt für Klarheit und erleichtert Entwicklern das Verständnis der API-Nutzung.
Bessere Tests – API-Spezifikationen können verwendet werden, um Tests automatisch zu generieren und auszuführen. So lässt sich sicherstellen, dass die API-Implementierung dem Vertrag entspricht und wie erwartet funktioniert. Dadurch können Probleme mit einer API erkannt werden, bevor sie in der Produktionsumgebung veröffentlicht wird.
Verbesserte Sicherheit – Fortschrittliche Sicherheitstools können mithilfe der OpenAPI-Spezifikation den API-Datenverkehr und das Nutzerverhalten analysieren. Sie können Positive Security<.htmla> anwenden, indem sie überprüfen, ob API-Anfragen den vom API-Endpunkt unterstützten Methoden, Endpunkten und Parametern entsprechen. Nicht konformer Datenverkehr wird standardmäßig blockiert, wodurch sich die Anzahl der Aufrufe reduziert, die Ihre Microservices verarbeiten müssen.
Einfachere Weiterentwicklung – API-Spezifikationen erleichtern die kontinuierliche Weiterentwicklung des API-Vertrags und der Anwendung, indem sie eine klare und standardisierte Möglichkeit bieten, Änderungen sowohl in maschinen- als auch in menschenlesbaren Formaten zu dokumentieren und zu kommunizieren. In Verbindung mit geeigneten Versionierungsverfahren trägt dies dazu bei, die Auswirkungen von API-Änderungen auf API-Nutzer zu minimieren und die Abwärtskompatibilität einer API sicherzustellen.

Insgesamt kann die Verwendung einer gemeinsamen API-Spezifikation dazu beitragen, die Interoperabilität, Dokumentation, Tests, Sicherheit und schrittweise Weiterentwicklung einer API zu verbessern.

Wie NGINX die API-First-Softwareentwicklung unterstützt

NGINX bietet eine Reihe schlanker, cloudnativer Tools, mit denen sich APIs in großem Umfang einfach betreiben, überwachen, verwalten und absichern lassen. Beispielsweise bietet der API Connectivity Manager als Teil der F5 NGINX Management Suite eine zentrale Verwaltungsebene für Ihren API-Betrieb. Damit können Sie API-Gateways und Entwicklerportale konfigurieren und verwalten. Da das Tool selbst nach dem API-First-Prinzip konzipiert ist, ist jede Funktion über eine REST-API zugänglich, was die CI/CD-Automatisierung und Integration für DevOps-Teams vereinfacht.

Mithilfe der OpenAPI-Spezifikation können Sie NGINX-Produkte für folgende Aufgaben verwenden:

APIs auf dem API-Gateway veröffentlichen
API-Dokumentation für das Entwicklerportal generieren
Positive Sicherheit zum Schutz von API-Endpunkten anwenden

Verwenden Sie die OpenAPI-Spezifikation, um eine API im API-Gateway und die zugehörige Dokumentation im Entwicklerportal zu veröffentlichen sowie Sicherheitsrichtlinien für die WAF über CI/CD-Pipelines oder die Benutzeroberfläche festzulegen.

APIs im API-Gateway veröffentlichen

API Connectivity Manager verwendet die OpenAPI-Spezifikation, um die Veröffentlichung und Verwaltung von APIs zu optimieren. API-Entwickler können APIs entweder über die Benutzeroberfläche der NGINX Management Suite oder über die vollständig deklarative REST-API im API-Gateway veröffentlichen. APIs werden dem Gateway als API-Proxys hinzugefügt. Diese enthalten alle Ingress-, Backend- und Routing-Konfigurationen, die das API-Gateway benötigt, um eingehende API-Anfragen an den Backend-Microservice weiterzuleiten. Mithilfe der REST-API können Sie APIs als Code bereitstellen und verwalten, indem Sie mit Tools wie Ansible einfache CI/CD-Automatisierungsskripte erstellen.

Eine vollständige Anleitung zur Verwendung der OpenAPI-Spezifikation für die Veröffentlichung einer API finden Sie in der Dokumentation zu API Connectivity Manager.

API-Dokumentation für das Entwicklerportal generieren

Die Pflege der Dokumentation ist für API-Teams oft mit erheblichem Aufwand verbunden. Veraltete Dokumentation in Entwicklerportalen ist jedoch auch ein deutliches Anzeichen für eine unkontrollierte Ausbreitung von APIs. API Connectivity Manager nutzt die OpenAPI-Spezifikation, um automatisch Dokumentation zu erstellen und im Entwicklerportal zu veröffentlichen. Das spart API-Entwicklern Zeit und stellt sicher, dass API-Nutzer stets die benötigten Informationen finden. Sie können OpenAPI-Spezifikationsdateien direkt über die Benutzeroberfläche oder die REST API von API Connectivity Manager hochladen.

Eine vollständige Anleitung zur Veröffentlichung der API-Dokumentation im Entwicklerportal finden Sie in der Dokumentation zu API Connectivity Manager.

Positive Sicherheit zum Schutz von API-Endpunkten anwenden

Sie können die OpenAPI-Spezifikation auch verwenden, um zu überprüfen, ob API-Anfragen an das NGINX Plus API-Gateway den von einer API unterstützten Funktionen entsprechen. Durch die Anwendung positiver Sicherheit (eines Sicherheitsmodells, das festlegt, was zulässig ist, und alles andere blockiert) können Sie verhindern, dass böswillige Anfragen Ihre Backend-Dienste auf potenzielle Schwachstellen untersuchen.

Zum Zeitpunkt der Erstellung dieses Dokuments können Sie den API Connectivity Manager nicht zur Konfiguration von NGINX App Protect WAF verwenden. Diese Funktion wird im weiteren Verlauf des Jahres 2023 verfügbar sein. Sie können jedoch den Instance Manager (ein weiteres Modul der NGINX Management Suite) und die OpenAPI-Spezifikation verwenden, um benutzerdefinierte Richtlinien für Ihre WAF zu erstellen. Weitere Informationen finden Sie in der Dokumentation zu NGINX App Protect WAF und zum Instance Manager.

Weitere Informationen zu API-Sicherheit und Bedrohungsmodellierung sowie zur Anwendung von Authentifizierung und Autorisierung am API-Gateway finden Sie in Kapitel 7 von „Mastering API Architecture“.

Zusammenfassung

Ein API-First-Ansatz bei der Entwicklung von Microservices und Anwendungen kann Ihrem Unternehmen in vielerlei Hinsicht zugutekommen. Wenn sich Teams an der OpenAPI Specification (oder einer anderen gemeinsamen API-Spezifikation, die sowohl für Menschen als auch für Maschinen lesbar ist) orientieren, erleichtert dies die teamübergreifende Zusammenarbeit, Kommunikation und den Betrieb.

Moderne Anwendungen werden in komplexen, Cloud-nativen Umgebungen betrieben. Die Einführung von Tools, die einen API-First-Ansatz für den Betrieb von APIs ermöglichen, ist ein entscheidender Schritt zur Umsetzung Ihrer API-First-Strategie. Mit NGINX können Sie die OpenAPI-Spezifikation nutzen, um Ihre APIs team- und umgebungsübergreifend in großem Maßstab zu verwalten.

Starten Sie eine 30-tägige kostenlose Testversion der NGINX Management Suite, die Zugriff auf den API Connectivity Manager, NGINX Plus als API-Gateway sowie auf NGINX App Protect zum Schutz Ihrer APIs umfasst.