Die Vorteile eines API-First-Ansatzes zum Erstellen von Microservices

APIs sind das Bindegewebe von Cloud-nativen Anwendungen – das Mittel, mit dem die Microservices-Komponenten einer Anwendung kommunizieren. Mit dem Wachstum und der Skalierung von Anwendungen steigt auch die Anzahl der Microservices und APIs. Obwohl dies in den meisten Fällen ein unvermeidbares Ergebnis ist, stellt es die Platform-Ops -Teams, die für die Gewährleistung der Zuverlässigkeit, Skalierbarkeit und Sicherheit moderner Anwendungen verantwortlich sind, vor erhebliche Herausforderungen. Wir nennen dieses Problem API-Wildwuchs und haben in einem früheren Blog-Beitrag darüber geschrieben.

Als ersten Versuch, der API-Ausbreitung Einhalt zu gebieten, könnte ein Unternehmen einen Top-down-Ansatz verfolgen, indem es Tools zur automatischen API-Erkennung und -Behebung implementiert. Dies ist zwar kurzfristig effektiv, stellt jedoch häufig eine unangemessene Belastung der Teams dar, die für die Erstellung und den Betrieb von APIs und Microservices verantwortlich sind. Sie müssen entweder vorhandene Microservices und APIs überarbeiten, um Sicherheits- und Compliance-Probleme zu lösen, oder einen mühsamen Überprüfungsprozess durchlaufen, um die erforderlichen Genehmigungen zu erhalten. Aus diesem Grund verfolgen viele große Softwareunternehmen einen dezentralen Ansatz, der den Entwicklern mithilfe adaptiver Governance die Autonomie gibt, die sie benötigen .

Anstatt in letzter Minute Sicherheitsvorkehrungen zu treffen, ist eine Bottom-up-Herangehensweise an das Problem auf lange Sicht wirksamer. Als Erstes werden die Teams einbezogen, die APIs für verschiedene Mikrodienste und Anwendungen erstellen und betreiben. Häufig beginnen sie damit, einen API-First- Ansatz für die Softwareentwicklung in Ihrem Unternehmen zu verfolgen.

Was ist API-First?

APIs gibt es schon seit Jahrzehnten. Allerdings handelt es sich dabei nicht mehr einfach um „Anwendungsprogrammierschnittstellen“. Im Kern sind APIs Entwicklerschnittstellen. Wie jede Benutzeroberfläche müssen APIs geplant, entworfen und getestet werden. Bei „API-First“ geht es darum, die Bedeutung von Konnektivität und Einfachheit für alle Teams, die APIs betreiben und verwenden, anzuerkennen und zu priorisieren. Es priorisiert Kommunikation, Wiederverwendbarkeit und Funktionalität für API-Verbraucher, die fast immer Entwickler sind.

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 zur Softwareentwicklung das Endziel. In der Praxis bedeutet dieser Ansatz, dass die API vor der Implementierung vollständig definiert wird. Die Arbeit beginnt mit dem Entwerfen und Dokumentieren der Funktionsweise der API. Das Team verlässt sich auf das resultierende Artefakt, das oft als API-Vertrag bezeichnet wird, um Informationen darüber zu erhalten, wie es die Funktionalität der Anwendung implementiert.

Entdecken Sie Designtechniken zur Unterstützung eines API-First-Ansatzes für die Softwareentwicklung, der sowohl dauerhaft als auch flexibel ist, in Kapitel 1 des eBooks „Mastering API Architecture“ von O'Reilly, mit freundlicher Genehmigung von NGINX.

Der Wert von API-First für Organisationen

Für Microservices-Architekturen ist häufig eine API-First-Strategie ideal, da sie gewährleistet, dass Anwendungsökosysteme von Anfang an als modulare und wiederverwendbare Systeme fungieren. Die Einführung eines API-First-Softwareentwicklungsmodells 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 Microservices arbeiten, die von den APIs der Anwendungen abhängen. Die Zusammenarbeit über den gesamten API-Lebenszyklus hinweg ist häufig einfacher, da jedes Team auf den etablierten API-Vertrag verweisen kann.
• Verbessertes Entwicklererlebnis – Beim API-First-Design steht das Entwicklererlebnis im Vordergrund, indem sichergestellt wird, dass eine API logisch und gut dokumentiert ist. Dies schafft ein nahtloses Erlebnis für Entwickler, wenn sie mit einer API interagieren. Erfahren Sie, warum es für Platform Ops-Teams so wichtig ist , die Erfahrung der API-Entwickler zu berücksichtigen<.htmla>.
• Einheitliche Governance und Sicherheit – Cloud- und Plattformarchitekten können das API-Ökosystem auf einheitliche Weise organisieren, indem sie während der API-Entwurfsphase Sicherheits- und Governance-Regeln integrieren. Dadurch werden die erforderlichen kostspieligen Überprüfungen vermieden, wenn später im Softwareprozess Probleme entdeckt werden.
• Verbesserte Softwarequalität – Durch die frühzeitige Entwicklung von APIs wird sichergestellt, dass die Sicherheits- und Compliance-Anforderungen bereits früh im Entwicklungsprozess erfüllt werden, lange bevor die API für die Produktion bereit ist. Da in der Produktion weniger Sicherheitsmängel behoben werden müssen, haben Ihre Betriebs-, Qualitäts- und Sicherheitstechnikteams mehr Zeit, direkt mit den Entwicklungsteams zusammenzuarbeiten, um sicherzustellen, dass die Qualitäts- und Sicherheitsstandards in der Entwurfsphase eingehalten werden.
• Schnellere Markteinführung – Mit weniger Abhängigkeiten und einem konsistenten Rahmen für die Kommunikation zwischen den Diensten können verschiedene Teams ihre Dienste viel effizienter erstellen und verbessern. Eine konsistente, maschinenlesbare API-Spezifikation ist ein Tool, das Entwicklern und Platform-Ops-Teams dabei helfen kann, besser zusammenzuarbeiten .

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 hilfreich sein kann

In der typischen Microservices- und API-Landschaft eines Unternehmens sind mehr Komponenten im Spiel, als ein Platform-Ops-Team täglich im Auge behalten kann. Durch die Einführung und Übernahme einer standardisierten, maschinenlesbaren API-Spezifikation können Teams die derzeit in ihren Umgebungen aktiven APIs besser verstehen, überwachen und Entscheidungen dazu treffen.

Die Einführung einer gemeinsamen API-Spezifikation kann auch dazu beitragen, die Zusammenarbeit mit den Beteiligten während der API-Entwurfsphase zu verbessern. Indem Sie einen API-Vertrag erstellen und ihn in einer Standard-Spezifikation formalisieren, können Sie sicherstellen, dass alle Beteiligten sich über die Funktionsweise einer API einig sind. Darüber hinaus wird dadurch die gemeinsame Nutzung wiederverwendbarer Definitionen und Funktionen durch mehrere Teams erleichtert.

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 APIs in der Produktion aus und die OpenAPI-Spezifikation ist die Standardmethode zum Schreiben einer API-Definition für eine REST-API. Sie bietet einen maschinenlesbaren Vertrag, der beschreibt, wie eine bestimmte API funktioniert. Die OpenAPI-Spezifikation wird von einer Vielzahl von API-Management- und API-Gateway-Tools, einschließlich NGINX, umfassend unterstützt. Der Rest dieses Blogs konzentriert sich darauf, wie Sie die OpenAPI-Spezifikation verwenden können, um einige wichtige Anwendungsfälle umzusetzen.

Die OpenAPI-Spezifikation ist ein Open-Source-Format zum Definieren von APIs in JSON oder YAML. Sie können ein breites Spektrum an API-Eigenschaften einbinden, wie das folgende einfache API-Beispiel zeigt. Hier gibt eine einfache HTTP- GET- Anfrage eine Liste mit Artikeln einer imaginären Einkaufsliste zurück.

Öffnen Sie API: 3.0.0info:
Version: 1.0.0
Titel: Einkaufsliste API
Beschreibung: Eine Beispiel-API zur Veranschaulichung der OpenAPI-Spezifikation

Server:
URL: https://api.example.io/v1

Pfade:
/Liste:
Abrufen:
Beschreibung: Gibt eine Liste der Dinge zurück, die auf Ihrer Einkaufsliste stehen.

Antworten:
        '200':
Beschreibung: Eine Liste wurde erfolgreich zurückgegeben
Inhalt:
Schema:
Typ: Array
Elemente:
Typ: Objekt
Eigenschaften:
Elementname:
Typ: Zeichenfolge

Definitionen, die der OpenAPI-Spezifikation folgen, sind sowohl für Menschen als auch für Maschinen lesbar. Dies bedeutet, dass es eine einzige zuverlässige Quelle gibt, die die Funktionsweise der einzelnen APIs dokumentiert. Dies ist insbesondere in Organisationen wichtig, in denen viele Teams APIs erstellen und betreiben. Um APIs in großem Maßstab zu verwalten, zu steuern und zu sichern, müssen Sie natürlich sicherstellen, dass die restlichen Tools Ihrer API-Plattform – API-Gateways, Entwicklerportale und erweiterte Sicherheit – auch die OpenAPI-Spezifikation unterstützen.

Erfahren Sie in Kapitel 1 von „Mastering API Architecture“ mehr über die Entwicklung von REST-APIs mithilfe der OpenAPI-Spezifikation.

Vorteile der Einführung einer gemeinsamen API-Spezifikation

Die Verwendung einer gemeinsamen API-Spezifikation, etwa der OpenAPI-Spezifikation, bietet mehrere Vorteile:

• Verbesserte Interoperabilität – Eine gemeinsame, maschinenlesbare Spezifikation bedeutet, dass verschiedene Systeme und Clients den API-Vertrag nutzen und verwenden können. Dies erleichtert Platform-Ops-Teams die Integration, Verwaltung und Überwachung komplexer Architekturen.
• Einheitliche Dokumentation – Der API-Vertrag wird in einem Standardformat dokumentiert, einschließlich der Endpunkte, Anforderungs- und Antwortformate und anderer relevanter Details. Viele Systeme können den Vertrag nutzen, um eine umfassende Dokumentation zu erstellen, die für Klarheit sorgt und es Entwicklern erleichtert, die Verwendung der API zu verstehen.
• Besseres Testen – API-Spezifikationen können zum automatischen Generieren und Ausführen von Tests verwendet werden. Dies kann dazu beitragen, sicherzustellen, dass die API-Implementierung dem Vertrag entspricht und wie erwartet funktioniert. Dies kann dazu beitragen, Probleme mit einer API zu erkennen, bevor sie in der Produktion veröffentlicht wird.
• Verbesserte Sicherheit – Erweiterte Sicherheitstools können die OpenAPI-Spezifikation verwenden, um API-Verkehr und Benutzerverhalten zu analysieren. Sie können positive Sicherheit<.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 die Anzahl der Anrufe reduziert wird, die Ihre Microservices verarbeiten müssen.
• Einfachere Weiterentwicklung – API-Spezifikationen können die Weiterentwicklung des API-Vertrags und der Anwendung selbst im Laufe der Zeit erleichtern, indem sie eine klare und standardisierte Möglichkeit bieten, Änderungen in maschinen- und menschenlesbaren Formaten zu dokumentieren und zu kommunizieren. In Verbindung mit geeigneten Versionierungspraktiken trägt dies dazu bei, die Auswirkungen von API-Änderungen auf API-Verbraucher zu minimieren und sicherzustellen, dass eine API abwärtskompatibel bleibt.

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 leichter, Cloud-nativer Tools, die den Betrieb, die Überwachung, die Verwaltung und die Sicherung von APIs im großen Maßstab vereinfachen. Beispielsweise bietet der API Connectivity Manager , Teil der F5 NGINX Management Suite , eine einzige Verwaltungsebene für Ihre API-Operationen. Damit können Sie API-Gateways und Entwicklerportale konfigurieren und verwalten. Da es sich hierbei um ein API-First-Tool handelt, ist jede Funktion über die 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 Folgendes nutzen:

• Veröffentlichen von APIs im API-Gateway
• Generieren einer API-Dokumentation für das Entwicklerportal
• Wenden Sie positive Sicherheit an, um API-Endpunkte zu schützen

Veröffentlichen von APIs im API-Gateway

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 die vollständig deklarative REST-API im API-Gateway veröffentlichen. APIs werden dem Gateway als API-Proxys hinzugefügt, die alle Ingress-, Backend- und Routing-Konfigurationen enthalten, die das API-Gateway benötigt, um eingehende API-Anfragen an den Backend-Mikroservice weiterzuleiten. Sie können die REST-API verwenden, um APIs als Code bereitzustellen und zu verwalten, indem Sie einfache CI/CD-Automatisierungsskripte mit Tools wie Ansible erstellen.

Vollständige Anweisungen zur Verwendung der OpenAPI-Spezifikation zum Veröffentlichen einer API finden Sie in der API Connectivity Manager-Dokumentation .

Generieren der API-Dokumentation für das Entwicklerportal

Die Pflege der Dokumentation bereitet API-Teams oft Kopfschmerzen. Aber auch veraltete Dokumentationen auf Entwicklerportalen sind ein Hauptsymptom für die Ausbreitung von APIs. API Connectivity Manager verwendet die OpenAPI-Spezifikation, um automatisch Dokumentationen zu generieren und sie im Entwicklerportal zu veröffentlichen. Dadurch sparen API-Entwickler Zeit und API-Verbraucher können immer finden, was sie brauchen. Sie können OpenAPI-Spezifikationsdateien direkt über die Benutzeroberfläche des API Connectivity Managers oder die REST-API hochladen.

Vollständige Anweisungen zum Veröffentlichen der API-Dokumentation im Entwicklerportal finden Sie in der API Connectivity Manager-Dokumentation .

Wenden Sie positive Sicherheit an, um API-Endpunkte zu schützen

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 Anforderungen entsprechen. Durch die Anwendung positiver Sicherheit (ein Sicherheitsmodell, das definiert, was zulässig ist und alles andere blockiert) können Sie verhindern, dass böswillige Anfragen Ihre Backend-Dienste auf potenzielle Schwachstellen prüfen.

Zum Zeitpunkt des Schreibens können Sie API Connectivity Manager nicht verwenden, um NGINX App Protect WAF zu konfigurieren. Diese Funktion wird später im Jahr 2023 verfügbar sein. Sie können jedoch Instance Manager (ein weiteres Modul der NGINX Management Suite) und die OpenAPI-Spezifikation verwenden, um benutzerdefinierte Richtlinien für Ihre WAF zu schreiben. Weitere Informationen finden Sie in der Dokumentation zu NGINX App Protect WAF und Instance Manager .

Erfahren Sie mehr über API-Sicherheit und Bedrohungsmodellierung und wie Sie Authentifizierung und Autorisierung am API-Gateway anwenden in Kapitel 7 von „Mastering API Architecture“ .

Zusammenfassung

Ein API-First-Ansatz zum Erstellen von Microservices und Anwendungen kann Ihrem Unternehmen in vielerlei Hinsicht zugute kommen. Durch die Ausrichtung der Teams auf die OpenAPI-Spezifikation (oder eine andere allgemeine API-Spezifikation, die sowohl für Menschen als auch für Maschinen lesbar ist) werden die Zusammenarbeit, Kommunikation und Abläufe zwischen Teams erleichtert.

Moderne Anwendungen laufen in komplexen, Cloud-nativen Umgebungen. Die Einführung von Tools, die einen API‑First-Ansatz zum Betrieb von APIs ermöglichen, ist ein entscheidender Schritt zur Umsetzung Ihrer API‑First-Strategie. Mit NGINX können Sie die OpenAPI-Spezifikation verwenden, um Ihre APIs in großem Maßstab über verteilte Teams und Umgebungen hinweg zu verwalten.

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