Es war ein hektischer Monat für WSO2; die Einführung des neuen Enterprise Integrators 7.0.0, des kommenden Enterprise Integrators 6.6.0, des Identity Servers 5.9.0 und das Thema dieses Blogs, der API Manager 3.0.0. Wir berichten über die Neuerungen im neuen WSO2 API Manager aus einer High-Level Perspektive. Wir betrachten die Änderungen, die in den Release Notes und der Dokumentation angegeben sind, aber wir machen keinen ausführlichen Test- oder Erfahrungsblog. Da aber ein reiner Textblog langweilig ist, zeige ich ein paar Screenshots des Publishers und des neuen Devportals (ehemals der Store).
Figure 1: The Management UI is quite familiarEine neue Version
Aber was ist neu in dieser Version? Nun, eine Reihe von Dingen wie
- API-Monetarisierung
- JWT-Authentifizierung
- API-Schema-Prüfer
- GraphQL-API-Unterstützung
- Bot-Erkennung
- API-Produkt
Schauen wir uns diese Funktionalitäten einmal genauer an.
Monetarisierung
Monetarisierung war schon immer eine Möglichkeit des WSO2 API Managers. Im API Manager 3.0.0 gibt es mehr Unterstützung für die API-Monetarisierung. Wir können eine Abrechnungs-Engine eines Drittanbieters integrieren, indem wir die verfügbaren steckbaren Erweiterungspunkte in WSO2 API Manager verwenden. Der Payment Provider Stripe ist der Beispiel-Provider für eine Out Of The Box (OOTB) Version des API Managers. Eine interessante Entwicklung, die wir im nächsten Jahr untersuchen und wahrscheinlich auch in die WSO2 API Manager-Schulung für Fortgeschrittene aufnehmen werden, die wir gerade aktualisieren.
Sichern von APIs
Neben der Möglichkeit, ein Oauth2-Token zu verwenden, besteht nun auch die Möglichkeit, JWT-Authentifizierung als Alternative zum Aufrufen von APIs zu verwenden. Der WSO2 API Manager unterstützt die Verwendung von in sich geschlossenen und signierten JWT-formatierten OAuth2.0-Zugriffstoken als API-Anmeldeinformationen. Wenn ein API mit dem OAuth2-Sicherheitsschema gesichert ist, können die JWT-Tokens, die für die Benutzer vom Entwicklerportal ausgestellt werden, zum Aufrufen von APIs verwendet werden.
API-Schema-Validierung
WSO2 API Manager ermöglicht es Anwendern, ihre OpenAPI-Definitionen zu verwenden und die Validierung von Anfragen und Antworten ohne zusätzlichen Aufwand (z. B. durch die Implementierung benutzerdefinierter Mediationen usw.) durchzusetzen. Das heißt, bevor der Aufruf an das Backend geht, wird das Schema validiert und falls die Validierung fehlschlägt, sendet das Gateway einen 400-Statuscode (bad request error), dasselbe gilt für die Validierung der Antwort, in diesem Fall wird ein 500-Statuscode gesendet (internal server error).
GraphQL
Neben SOAP, REST und Websockets können Anwender GraphQL-Schemata verwenden, um GraphQL-APIs im WSO2 API Manager zu entwerfen. Damit können API Manager-Benutzer ihre GraphQL-Dienste als APIs verwalten. GraphQL ist eine neuartige Abfragesprache für Ihre API. Sie können beispielsweise eine MySQL-Datenbank nehmen und eine GraphQL-Schicht darüber legen, die es der API ermöglicht, die Datenbank abzufragen. Der GraphQL-Standard ist offen, wird aber von Facebook vorangetrieben.
Bot-Erkennung
Damit der API Manager weniger angreifbar ist, wurde eine Bot-Erkennung eingeführt. Diese Fähigkeit im WSO2 API Manager benachrichtigt Admin-Benutzer per E-Mail über Aufrufe von offenen APIs und APIs ohne ordnungsgemäße Authentifizierung. Diese können durch Bots und Angreifer erfolgen, können aber auch einfach ein Fehler von Entwicklern während des Entwicklungsprozesses sein. In dieser Version gibt es weitere Verbesserungen, die mit der Sicherheit zu tun haben, wie z. B. Schutz vor json/xml-Bedrohungen.
Kombinieren und anpassen
Eine weitere interessante Funktion ist die Möglichkeit, mehrere APIs zu integrieren und sie als ein einziges Produkt darzustellen. Dies hilft dabei, verschiedene Dienste auf unterschiedliche Art und Weise zu verpacken und sie als separate Produkte darzustellen. Natürlich kann dies auch durch die Definition verschiedener APIs geschehen, aber das API-Produkt ist ein neuer Ansatz dazu.
Zurück zum API-Manager
Der API-Manager 3.0.0 läuft auf Java 8 und 11. Dieses Verhalten haben wir auch beim Identity Server 5.9.0 gesehen, also gehen wir davon aus, dass er auf dem gleichen 4.5.1 Carbon-Kern (auch bekannt als Minsky) läuft. Dies bedeutet natürlich, dass wir die deployment.toml haben, um die Konfiguration zu vereinfachen. Dadurch können Sie alle Konfigurationsänderungen in einer Datei (deployment.toml) vornehmen und nicht in all den anderen Konfigurationsdateien im Verzeichnis /conf. Das alte Konfigurationsmodell ist immer noch vorhanden und kann verwendet werden, aber dies ist eine große Verbesserung.
Figure 2: Logging in on the API Manager PublisherEine Reihe von Verbesserungen und allgemeinen Änderungen wurden am API-Manager vorgenommen, aber die offensichtlichsten Änderungen betreffen die am häufigsten verwendeten Komponenten, den Publisher und das Devportal (früher Store). Schauen wir uns einmal an, was sich geändert hat.
Publisher
Solange ich mich erinnern kann, war der Herausgeber der Ort, an dem Sie Ihre APIs definiert haben. Dies war ein dreistufiger Prozess, bei dem definiert wurde, wie das API aussieht, wo das API laufen wird (und Punkte) und schließlich definiert wurde, welche Personen in welchem Umfang Zugriff haben werden. Das ist ein mehr oder weniger langwieriger Prozess, der 10 bis 15 Minuten dauert, um alles auszufüllen, zumindest ist das meine Erfahrung, wenn ich WSO2 API Manager training gebe.
Die zum Produkt gehörenden Jaggery-Apps wurden auf ReactJS umgestellt. Der Publisher hat ein neues Look and Feel und einen deutlich anderen Ansatz. Nicht nur, dass wir eine neue Option bei der Definition einer API (GraphQL SDL Schema) sehen, wenn wir mit der Definition einer neuen API beginnen, erkennen wir den Unterschied. Die neue Version des API-Managers Version 3.0.0 hat so etwas wie einen kurzen Weg dazu.
Figure 3: Short track to API definitionDas Anlegen oder Definieren einer API geschieht auf der hohen Ebene mit nur ein paar Feldern, die ausgefüllt werden müssen. Sie brauchen den Namen, den Kontext, die Version, den Endpunkt und die Ebenen auszufüllen, etwas, das jetzt als Geschäftsplan bezeichnet wird.
Das war es schon. Aber wie sieht es mit all den anderen Einstellungen aus, die notwendig sind? Das wird alles in den nächsten Schritten erledigt.
Standardmäßig wird ein „get/post/put/delete/head/“ auf der Platzhalterressource (/*) erstellt.
Figure 4: The API is visible in Publisher and can be configured / finetuned
Figure 5: Config optionsNach einem Klick auf Erstellen und Veröffentlichen ist die API sowohl im Devportal (früher als Store bekannt) als auch im Publisher verfügbar. Im Publisher können Sie Änderungen an der Definition der API vornehmen, so wie wir es im API Manager 2.6.0 als Teil eines durchgängigeren Ablaufs mit den drei Registerkarten, die eine API definieren, getan hätten. Alle in der älteren Version verfügbaren Optionen sind jetzt als separate Optionen konfigurierbar. Inklusive der neuen Monetarisierungsoption, die jetzt verfügbar ist.
Nach der Festlegung können wir uns auf das Abonnement im Devportal konzentrieren. Personen, die mit dem Publisher vertraut sind, werden sich vielleicht fragen, wo die Analytics geblieben sind. Bisher waren sie im Publisher enthalten. Die Antwort ist, dass sie sich jetzt im separaten Analytics Dashboard befinden und nicht mehr im Publisher sichtbar sind.
Bye bye Store, Hallo Devportal
Der API-Store existiert nicht mehr und wurde durch ein Devportal ersetzt.
Figure 6: Hello DevportalDas ist die Übersicht, wenn Sie als Admin angemeldet sind. Wenn Sie auf die API klicken, erhalten Sie die gleiche Art von Übersicht, wie wir sie im Publisher sehen. Das Erscheinungsbild mag anders sein, aber die Funktionalität ist weitgehend die gleiche.
Figure 7: Looking at the API and about to subscribe and try outWenn wir die Definition der API abgeschlossen haben, gehen wir in den Store, um die API mit einer Anwendung zu abonnieren. Sie können sich mit einer Anwendung bei der API anmelden und dabei Oauth2- oder JWT-Tokens für die Autorisierung generieren. Anschließend können Sie die API mit der bekannten Try it-Funktionalität ausprobieren.
Hip und aktuell!
Der neue Publisher und das Devportal sehen moderner und ein bisschen hipper aus. Die Verbesserungen, die ansonsten im API-Manager vorgenommen wurden, haben mehrere Vorteile, von der Fähigkeit, auf einer moderneren Java-Version (11) zu laufen, bis zur einfacheren Konfiguration mit der neuen toml-Datei. Und vieles, vieles mehr. Das ist der WSO2 API Manager, wie wir ihn kennen und lieben, aber jetzt sogar noch besser.
