fb
API Management 8 min

Erstellung einer API mit API Manager 4.1

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
api manager
Scrollen

Der neue WSO2 API Manager 4.1 ist ein stufenweises Update der Version 4.0. Die 4.x-Versionsreihe des Produkts brachte erhebliche Änderungen gegenüber den bisherigen 3.x-Versionen mit sich. Eine der wichtigsten Änderungen besteht darin, dass das Integrationsprofil und das API-Manager-Profil nun enger miteinander verbunden sind. Andererseits kennt das Internet keine Entfernungen. 

Damit meine ich, dass es wirklich nicht entscheidend ist, ob ein Proxy auf demselben Server oder auf einem anderen Server in einem anderen Rechenzentrum läuft. Auf diesem Block werde ich mich mit dem befassen, was ich als das A und O des API-Managers bezeichnen würde: die Erstellung einer API.

Was ist neu? Wie hat sich das Erstellen einer API verändert? Gibt es Neues, das wir tun können, und Altes, das wir nicht mehr tun können? Lassen Sie uns loslegen und es herausfinden!

Neue Architektur

Graphical user interface, application

Description automatically generated

In der Dokumentation finden Sie diese Übersicht über die neue Architektur, in der Sie das Vorhandensein von Streaming-Integrator und Mikro-Integrator deutlich sehen können. Sie stellt jedoch keinen Bestandteil des Downloads dar.

Die Installation des API-Managers 4.0.0 ist 432 Megabyte groß, was in etwa dem Download des API-Managers 3.2.0 (445 MB) entspricht. Es scheint also nicht viel hinzugefügt worden zu sein, es sei denn natürlich, es wurde etwas ausgetauscht.

Laut der Kompatibilitätsmatrix funktioniert API Manager 4.0.0 für Java 8 und Java 11. Laut WSO2 basiert API Manager 4.0.0 auf WSO2 Carbon 4.6.1 und soll mit allen WSO2-Produkten kompatibel sein, die auf einer Carbon 4.6.x-Version basieren.

Um das Ganze überschaubar zu halten, werde ich mich darauf konzentrieren, eine API zu erstellen, die die vorhandenen Änderungen aufzeigt. Ich werde nicht auf die unzähligen anderen Änderungen am Produkt eingehen.

Starten des API-Managers

Mit meiner aktuellen Java-Version (AdoptOpenJDK, Build 1.8.0_282-b08) starte ich den API-Manager. Hier können wir eine der ersten Änderungen feststellen. Die bekannte wso2server.sh oder bat wurde durch einen neuen Befehl apimanager.sh oder bat ersetzt. Dazu müssen wir lediglich auf die Datei klicken oder eine Terminal-Sitzung starten, wenn Sie mit Linux arbeiten. 

Es startet tatsächlich so, wie wir es gewohnt sind, mit dem Publisher Dev Portal und der Carbon Console, die als URLs angezeigt werden.

[2021-09-07 10:45:39,559]  INFO – CarbonUIServiceComponent Mgt Console URL  : https://localhost:9443/carbon/

[2021-09-07 10:45:39,559]  INFO – CarbonUIServiceComponent API Developer Portal Default Context : https://localhost:9443/devportal

[2021-09-07 10:45:39,559]  INFO – CarbonUIServiceComponent API Publisher Default Context : https://localhost:9443/publisher

Graphical user interface, application

Description automatically generated

Graphical user interface, application

Description automatically generated

Es gibt also eine neue Benutzeroberfläche, die wir sehen können, wenn wir uns anmelden. Die Bilder sind neu, aber die Funktionalität ist zum Teil unverändert. In früheren Versionen konnten wir Rest-APIs erstellen, die mit Soap-Services arbeiten [ich nenne diese nicht APIs, da APIs für mich ausschließlich Rest sind], Graph QL war auch verfügbar. Nur die Streaming-API ist neu, doch wenn wir sie anklicken, finden wir eine weitere Möglichkeit, die wir bereits nutzen konnten, und zwar Websockets.

Wenn Sie auf die einzelnen Felder klicken, sehen Sie genau, was Sie tun können:

und wie Sie sehen können, handelt es sich um eine Kombination aus bekannten Funktionen und ein paar wirklich neuen Funktionen wie Webhook-API, SSE-API und asynchroner API. Diese sind tatsächlich neu und bieten neue Funktionen, wobei ich mir nicht sicher bin, ob ich sie aufgrund der bereits erwähnten Verbindung von API und REST als APIs bezeichnen würde. Aber nichtsdestotrotz ist dies eine Erweiterung des Produkts. Dieser erste Blog über API Miniature 4.1 befasst sich mit einer echten Rest-API, die von Grund auf neu entwickelt wird.

Erstellung einer API von Grund auf

Lassen Sie uns also eine neue API entwerfen. Klicken Sie auf „Von vorne anfangen“ und lassen Sie uns schauen, was das nächste Fenster bereithält.

Nun, ich würde sagen, dass dies eine vertraute Schnittstelle ist, denn im Vergleich zur vorherigen Schnittstelle haben wir jetzt eine kleinere Liste, die wir eingeben müssen, da die Geschäftspläne jetzt nicht mehr Teil des ersten Schritts sind.

Lassen Sie uns also eine erste API namens myfirstAPI erstellen. Füllen Sie die Details wie folgt aus.

Graphical user interface, application

Description automatically generated

Klicken Sie auf Create & Publish und Sie können sehen, dass die API erstellt wurde. 

Graphical user interface

Description automatically generated

Wir können die API jetzt direkt über das Entwicklerportal ausprobieren. Dies ist jedoch keine neue Funktionalität. Diese Funktion war auch in 3.2.0 verfügbar.

Wie Sie der Übersicht entnehmen können, werden die bekannten Platzhalter-Ressourcen auf GET POST PUT DELETE und PATCH sowie der Geschäftsplan, der jetzt auf unbegrenzt eingestellt ist, erstellt. Auf diese Weise können Sie schnell eine API erstellen, allerdings sind die Einsatzmöglichkeiten einer solchen API in der Praxis äußerst begrenzt. Ich sage das deshalb, weil sowohl die Platzhalter-Ressourcen als auch der unbegrenzte Geschäftsplan ein typisches „Finger weg“ sind, wenn es um die API-Definition geht. Sie sollten die Ressourcen weitestgehend einschränken, indem Sie nur diejenigen anbieten, die mit dem Back-End kompatibel sind, und die Kriterien für die von diesen Ressourcen akzeptierten Eingaben einschränken. Der unbegrenzte Geschäftsplan ist auch etwas, das Sie in der Regel nicht nutzen würden, da er die Möglichkeit der Drosselung ausschließt.

Aber lassen Sie uns unsere API trotzdem ausprobieren, da es sich nur um einen einfachen Testaufbau handelt. Dafür wählen wir die Testfunktion des Herausgebers aus. Diese finden Sie in der linken unteren Ecke direkt oberhalb der Registerkarte „Lebenszyklus“.

Graphical user interface, application

Description automatically generated

Ich habe den Schlüssel generiert, bei dem es sich um einen JWT-Schlüssel handelt und der benötigt wird, um die API aufzurufen, da diese standardmäßig aktiviert ist. Nun klicken wir auf die Schaltfläche „Get“.

Graphical user interface, application

Description automatically generated

Wie Sie sehen, wurde die GET-Ressource der API erfolgreich aufgerufen. 

Sehen wir uns nun an, wie der neue API Manager die API-Elemente auflistet.

Neues Layout

Mit der neuen Ausgabe wurde das Layout des Herausgebers überarbeitet. Schauen wir uns einige der neuen interessanten Ergänzungen an, die mit der neuen Version eingeführt wurden.

Graphical user interface, application

Description automatically generated

Schauen wir uns zunächst die grundlegenden Informationen an.

Dazu gehören die GitHub-URL und die Slack-URL. Ansonsten sind die bekannten Elemente der API-Definition zu finden. 

Auf alle Aspekte einzugehen, würde ein wenig zu weit führen. Falls Sie Interesse haben, können Sie jederzeit an unserem API Manager 4.1.0 CORE-Training teilnehmen, um alle Aspekte kennenzulernen. 

Die folgenden Optionen sind ebenfalls gleich geblieben, wobei sich die Reihenfolge der Felder teilweise leicht geändert hat:

  • Geschäftsinformationen
  • Abonnements
  • Unterlagen
  • Kommentare
  • Laufzeit
  • Ressourcen
  • API-Definition
  • Endpunkte
  • Lokale Anwendungsbereiche
  • Eigenschaften
  • Monetarisierung
  • Lebenszyklus
  • Ausprobieren

Bereitstellungen

Bereitstellungen sind in dieser Version von API Manager neu. Da die API jetzt im Speicher erstellt wird (und nicht als dateibasierte API-Definition im Synapse-Verzeichnis), können wir jetzt Revisionen bereitstellen. Ich habe die API mit einem neuen Image erstellt und als Überarbeitung bereitgestellt. 

Das war die alte API aus Sicht des Devportals.

Graphical user interface, text, application, email

Description automatically generated
Graphical user interface, text, application, chat or text message

Description automatically generated
A picture containing chart

Description automatically generated

Jetzt sieht sie so aus. Beachten Sie, dass dies innerhalb des veröffentlichten Lebenszyklus bleibt. Ich kann zwischen Überarbeitungen wechseln und völlig neue Überarbeitungen bereitstellen. Was sagt die Dokumentation über Überarbeitungen ? Nun, tatsächlich recht viel. Unter dem Link finden Sie alle Informationen, aber das Wichtigste ist das Folgende. Um WSO2 zu zitieren:

Mit der Einführung von API und API-Produktüberarbeitungen wurden zuvor gekoppelte Veröffentlichungs- und Bereitstellungsvorgänge entkoppelt . Der API-Herausgeber hat eine bessere Kontrolle über die API-Bereitstellungen und kann wiederherstellbare Änderungen am API-Projekt vornehmen. API-Überarbeitungen sind vergleichbar mit einem zeitlichen Kontrollpunkt, der den derzeitigen Zustand der API zum Zeitpunkt der Erstellung der Überarbeitung erfasst. 

Wenn sich die Änderungen nachteilig auf die API auswirken, nachdem sie in einer Gateway-Umgebung bereitgestellt wurde, können Sie schnell zu einem früheren Zustand der API zurückkehren. Insgesamt können Sie bis zu fünf Überarbeitungen vornehmen, danach müssen Sie eine der Überarbeitungen entfernen.

Wenn Sie mehrere Gateways definieren, können Sie eine Überarbeitung auf einem Gateway testen und bei Erfolg auf dem anderen bereitstellen.

Graphical user interface, text, application, email

Description automatically generated

Suche nach der API

Die API-Definition wird in der Governance-Registry gespeichert, genauer gesagt im Verzeichnis /_system/governance/apimgt/applicationdata/apis/. Dort finden Sie auch alle Überarbeitungen. Nachfolgend sehen Sie die erste Überarbeitung.

Bedeutet das, dass wir das Synapse-Konfigurationsverzeichnis nicht mehr verwenden? Nein, für Vermittlungserweiterungen verwenden wir nach wie vor das Sequenzverzeichnis zum Hochladen der Dateien. Außerdem können Sie die Veröffentlichung von Api-Artefakten im Dateisystem wie bisher aktivieren, wenn Sie dies durch Änderung bestimmter Eigenschaften wünschen.

Richtlinien

Eine weitere wichtige Funktion, die mit Version 4.1 eingeführt wurde, sind Betriebsrichtlinien. Im Gegensatz zu früheren Versionen ist es jetzt möglich, Vermittlungsrichtlinien pro Ressource in API Manager einzuführen. Vor Version 4.1 war es nur möglich, Richtlinien in den In-/Out-Sequenzen hinzuzufügen. (Siehe unten)

Aber jetzt gibt es viel mehr Flexibilität, und Sie können mehrere Richtlinien per Drag-and-Drop in der Reihenfolge ihrer Ausführung ablegen, wie unten dargestellt. Sie können Richtlinien auch selbst definieren, indem Sie auf die Schaltfläche „Neue Richtlinie hinzufügen“ klicken.

Graphical user interface, text, application

Description automatically generated

Hinweis: Zum Zeitpunkt der Erstellung dieses Artikels unterstützt die API Manager-Version 4.1 nicht die Definition gemeinsamer Richtlinien, die von mehreren APIs gemeinsam genutzt werden. Operative Richtlinien werden nach der Deklaration zusammen mit der API gebündelt und gelten für diese spezielle API als lokal. Dies ist eine Abweichung von dem referenzbezogenen Common-Policy-Modell, das in früheren Versionen (sogar in 4.0) vorhanden war, jetzt aber herausgenommen wurde. Wie aus der Korrespondenz mit dem WSO2-Team hervorgeht, haben sie zugesagt, dies zu unterstützen (siehe Ausgabe: https: //github.com/wso2/api-manager/issues/111), sodass wir davon ausgehen können, dass das Problem behoben und zu gegebener Zeit in Form eines Updates zur Verfügung gestellt wird.

Ich habe Log Message in den Mediationsfluss der GET-Ressource aufgenommen.

Graphical user interface, application

Description automatically generated with medium confidence

Da Veröffentlichung und Bereitstellung jedoch entkoppelt sind, müssen wir eine neue Version erstellen und diese bereitstellen. 

Das muss man wirklich verstehen, da es sich von der Art und Weise unterscheidet, wie wir es in der Vergangenheit gemacht haben. Für mich als Ausbilder bedeutet das, dass das Schulungsmaterial für diesen neuen API Manager 4.1.0 geändert werden muss, weil sich der Mechanismus geändert hat.

Fazit

Die API Manager 4.x-Generation ist ein wichtiges Upgrade gegenüber früheren Versionen. Es hat sich einiges geändert. Ein paar kosmetische Dinge und wie wir gerade gesehen haben, gibt es neue Verfahren und Möglichkeiten. In den nächsten Blogs werde ich auf weitere Änderungen und neue Dinge eingehen, die wir mit dem API-Manager machen können.