So erweitern Sie die geschäftliche Reichweite mit ereignisgesteuerten APIs
Menaka Jayawardena, Associate Technical Lead bei WSO2, erläutert, wie Sie die geschäftliche Reichweite mit ereignisgesteuerten APIs erweitern können. Durch den Vergleich der grundlegenden Unterschiede zwischen herkömmlichen REST-APIs und neueren Async-APIs, Jayawardena hebt die Vorteile und damit verbundenen Herausforderungen hervor, die mit der Verwendung einer ereignisgesteuerten API einhergehen, um es einem Unternehmen zu ermöglichen, die geschäftliche Reichweite und Akzeptanz zu erweitern.
Heutzutage verlangen Kunden zunehmend Zugriff auf Echtzeitinformationen wie Aktienkurse, Zugzeiten usw. und sie erwarten, dass sie automatisch informiert werden, wenn sich etwas geändert hat, ohne dass sie auf die Schaltfläche „Aktualisieren“ klicken müssen. Die Bereitstellung dieser kritischen Informationen, sobald sie auftreten, ist eine herausfordernde Aufgabe für jedes Unternehmen. Traditionell erforderten Anwendungen Backend-Server, um die neuesten Informationen abzurufen; Dies erwies sich jedoch als ineffizient, da es eine erhebliche Anzahl von Ressourcen verbraucht.
Viele APIs, aus denen das Web heute besteht, sind synchrone APIs. Die Natur dieser Art von API ist eine Funktion des Zeitrahmens von der Anfrage bis zur Rückgabe von Daten und bietet eine Möglichkeit, geplante Anfragen nach Ressourcen, Daten oder Diensten zu stellen, wenn diese verfügbar sind. Polling ist ein gängiger Ansatz, aber der Prozess der regelmäßigen Anfragen an die Backends und das Warten auf Antworten wird mit der Zeit ineffizient.
APIs sollten so konzipiert sein, dass Benutzer einen Stream von Ereignissen vom Dienst empfangen können, anstatt ihn regelmäßig abzufragen. Ereignisgesteuerte APIs oder asynchrone (asynchrone) APIs können verwendet werden, um diese Anforderung zu erfüllen – mit unternehmenskritischen Informationen, die zum Zeitpunkt des Ereignisses an Clientanwendungen übertragen werden. Dies bietet eine viel bessere Erfahrung für Benutzer.
Asynchrone APIs vs. REST-APIs
REST-APIs für Kernverwaltungsfunktionen und Endbenutzerinteraktionen werden immer wichtiger, um sowohl lokale als auch Cloud-basierte Lösungen zu erstellen. RESTful-APIs sind flexibler, schneller, beliebter und skalierbarer. Sie werden jetzt gegenüber SOAP-APIs bevorzugt, die veraltet sind.
Im Gegensatz zu herkömmlichen Anforderungs-/Antwort-APIs (z. B. REST und SOAP) können asynchrone APIs mehrere Antworten auf eine einzelne Anforderung senden. Dies kann auch in Form einer unidirektionalen oder bidirektionalen Kommunikation erfolgen. Für asynchrone APIs können mehrere Protokolle verwendet werden, z. B. WebSocket, Webhooks, MQTT und Server-Sent Events (SSE). Die meisten dieser Protokolle unterstützen HTTP in der Phase der Verbindungserstellung und verwenden einen bestimmten Kanal, um die nachfolgenden Nachrichten zwischen dem Client und dem Server zu übertragen. Außerdem sind herkömmliche HTTP-Verben (dh GET, POST, PUT usw.) für diese Kanäle nicht gültig.
Ein weiterer wichtiger Unterschied zwischen einer REST-API und einer asynchronen API ist die Verwendung einer Event-Backbone-Technologie (ein Nachrichtenbroker wie Kafka oder RabbitMQ) und Themen. Die Backend-Dienste sind als Event-Publisher registriert und veröffentlichen Events zu bestimmten Themen. Clientanwendungen werden als Ereignisabonnenten für entsprechende Themen registriert, um diese von den Herausgeberdiensten veröffentlichten Ereignisse zu erhalten. Beim Empfang der Ereignisse führt der Client die erforderliche Verarbeitung durch und zeigt sie dem Benutzer an.
Da asynchrone APIs und REST-APIs konzeptionell unterschiedlich sind, ergeben sich mehrere einzigartige Herausforderungen, wenn ein herkömmliches System für asynchrone APIs verwendet wird. Dazu gehören Inkompatibilitäten mit bestehenden Sicherheitsmechanismen und Drosselungsrichtlinien sowie Probleme bei der Erfassung von Analysedaten. Die Bewältigung dieser Herausforderungen über eine geeignete API-Verwaltungslösung, die ereignisgesteuerte APIs vollständig unterstützt, ist ein Muss.
Sind Ihre ereignisgesteuerten APIs sicher?
API-Sicherheit kann in Authentifizierung und Autorisierung kategorisiert werden. Die Authentifizierung beschreibt, wer auf welche Ressource zugreifen kann, während die Autorisierung beschreibt, ob der authentifizierte Benutzer die bestimmte Aufgabe ausführen kann. In herkömmlichen REST-APIs können Benutzer mithilfe von Benutzeranmeldeinformationen, Zugriffstoken, zertifikatbasierter Authentifizierung usw. authentifiziert werden. Außerdem kann jede Ressource mit Bereichen geschützt werden, und jeder API-Aufruf kann ebenfalls geschützt werden. In asynchronen APIs gibt es jedoch nur Themen, für die die Clients und Dienste abonniert sind, und die Kommunikation erfolgt über ein dediziertes Messaging-Backbone. Es ist eine herausfordernde Aufgabe, APIs zu sichern.
Ein möglicher Ansatz für diese Herausforderung ist die Authentifizierung während der anfänglichen HTTP-Kommunikation. Beispielsweise können wir den anfänglichen WebSocket-Handshake (über HTTP) sichern, bevor die Verbindung hergestellt wird. Es ist auch möglich, die Autorisierung durchzusetzen, indem festgelegt wird, ob der Client Ereignisse veröffentlichen darf oder nicht.
Es gibt einige offene Endpunkte, die basierend auf bestimmten Anwendungsfällen keine Authentifizierung und Autorisierung erfordern.
Ratenbegrenzung, Drosselung und Monetarisierung
Sicherheit, Ratenbegrenzung, Drosselung, Monetarisierung und Analytik sind einige der wichtigen Faktoren, auf die sich ein Unternehmen konzentrieren sollte, wenn es seine Kerngeschäftsfunktionen als APIs offenlegt. Um diese anzugehen, muss ein Unternehmen die richtige API-Verwaltungslösung auswählen.
Meistens besteht das Endziel eines jeden Unternehmens, das APIs für externe Parteien bereitstellt, darin, Einnahmen zu generieren. Die Hauptanforderung dafür ist die Möglichkeit, die Nutzung der API einzuschränken (Zugriff blockieren, Bandbreite reduzieren usw.). API-Verwaltungssysteme unterstützen Ratenbegrenzung und Monetarisierung für REST/SOAP-APIs, indem sie Richtlinien verwenden, die auf der Anzahl der Anfragen basieren (Anfragen pro Sekunde/Minute, Bandbreite usw.). Wenn der Client die zulässige Anzahl von Anfragen überschreitet, wird der Client für einige Zeit blockiert.
Der Schutz von Back-End-Diensten vor Anfragenspitzen wird ebenfalls über diese Richtlinien gehandhabt, indem ein Limit für die Anfragerate eingeführt wird. Aber wenn es um asynchrone APIs geht, veröffentlichen Server die Ereignisse und Anwendungen sind die Ereignisabonnenten. Daher können herkömmliche Drosselungsrichtlinien nicht angewendet werden, da Server-Client-Ereignisse berücksichtigt werden müssen.
Die Definition von Drosselungsrichtlinien sollte ebenfalls geändert werden. Folgendes berücksichtigen:
Zeitbasierte Drosselung: Ein Client kann das Thema nur für eine bestimmte Zeit abonnieren. Danach wird der Client vom Server getrennt.
Auf der Ereignisanzahl basierende Drosselung: Ein Client kann nur x Anzahl von Ereignissen insgesamt empfangen. Dies kann auch mit zeitbasierter Drosselung kombiniert werden und Richtlinien erstellen (z. B. eine Zählung von 10000 Ereignissen pro Tag).
Backpressure-basierte Drosselung: Wenn der Client die Rate der empfangenen Ereignisse nicht bewältigen kann, wird das Gateway durch die Übermittlung der Nachrichten an den Client belastet – da es die Nachrichten in eine Warteschlange stellen und senden muss, wenn der Client sie annehmen kann. In diesen Situationen kann der Client vom Gateway entfernt werden, um sicherzustellen, dass das Gateway nicht beeinträchtigt wird.
Warum Analytics eine wichtige Rolle im API-Management spielt.
Analytics spielt eine wichtige Rolle in jedem API-gesteuerten Unternehmen und hilft dabei, fundierte Entscheidungen zu treffen, indem es Details wie die Anzahl der API-Konsumenten, die am häufigsten aufgerufenen API-Ressourcen, Latenzen und das Erkennen von Trends usw. bereitstellt. Es sollte eine obligatorische Funktion sein, die unterstützt wird durch ein API-Verwaltungsprodukt.
In herkömmlichen REST/SOAP-APIs kann ein API-Gateway Informationen wie das Aufrufen von API-Ressourcen, Backend-Latenzen, geografische Standorte usw. erfassen. Diese werden aus den Anforderungs-/Antwort-Headern abgerufen.
Bei asynchronen APIs wird die Erfassung dieser Informationen viel komplexer, da es keine HTTP-Anforderungen oder -Antworten gibt. Was wir haben, ist eine Reihe von Themen und Abonnenten. Alle Nachrichten werden über einen separaten Kanal gesendet (Server -> Client oder Client -> Server) und das Gateway sollte in der Lage sein, die erforderlichen Informationen zu erfassen. Für jeden Abonnenten der API sollte das Gateway Folgendes erfassen:
- Die Anzahl der gesendeten Nachrichten.
- Die TPS-Variation im Laufe der Zeit
- Die Anzahl der Veröffentlichungsfehler
- Zustandsdetails zum Backend (Endpunkt)
WEITERLESEN:
- Scaleup Spotlight: Climeworks ist der Schlüssel zur Bekämpfung des Klimawandels
- Wie Wi-Fi6 das hybride Arbeiten optimiert
- Welche europäischen Länder haben die beste und die schlechteste Cybersicherheit?
- McAfee: So machen Sie Telemedizin sicherer für ein bequemeres Leben im Internet
Ausweitung der Geschäftsreichweite und -akzeptanz
Die Verwendung ereignisgesteuerter APIs ist zum Schlüssel geworden, um die Kundenanforderungen zu erfüllen und eine bessere Benutzererfahrung zu bieten. Da es mehrere grundlegende Unterschiede zwischen REST- und asynchronen APIs gibt, kann die Verwendung einer Standard-API-Verwaltungslösung eine Herausforderung darstellen. Die richtige API-Verwaltungslösung sollte traditionelle API-Verwaltungsfunktionen mit einer ereignisgesteuerten Architektur kombinieren. Darüber hinaus bieten Anbieter jetzt Integrationssoftware mit Plug-and-Pay- und konfigurationsgesteuerten Ansätzen zur Implementierung asynchroner Messaging-Muster an. Dies wird einen enormen Mehrwert bieten und es einem Unternehmen ermöglichen, die Geschäftsreichweite und -akzeptanz zu erweitern.
Folge uns auf LinkedIn und Twitter
