Die Unterschiede zwischen APIs und Messaging für die Anwendungskommunikation

Phil Wilkins | Cloud Developer Evangelist, Oracle | Dezember 2022

Eine Software muss mit einer anderen Software sprechen. Manchmal muss Software in einem Teil einer Anwendung Services anfordern oder Daten mit einem anderen Teil der Anwendung austauschen. Oder eine Anwendung muss Dienste anfordern oder Daten mit einer ganz anderen Anwendung austauschen.

Es gibt zwei typische Mechanismen, die für diese Art der Kommunikation verwendet werden: Anwendungsprogrammierschnittstellen (APIs) und Messaging.

Die Unterschiede zwischen APIs und Messaging können manchmal verwirrend sein. Das liegt daran, dass die Begriffe sehr vieldeutig verwendet werden. Das Akronym API selbst hat zwar eine explizite Bedeutung, doch aus Gründen, die wir weiter unten erläutern werden, hat der Begriff mehrere verschiedene Bedeutungen angenommen. Messaging ist ein Begriff, der oft sehr lose verwendet wird, um fast jede System-zu-System-Kommunikation abzudecken. Lassen Sie uns also klären, was mit APIs und Messaging wirklich gemeint ist.

Eine detaillierte Definition von APIs

Grob gesagt ist eine API der Vertrag, der festlegt, wie eine Software Dienstanforderungen empfangen und beantworten kann. Der Vertrag wird von den Entwicklern der Software erstellt.

Klingt einfach? Ist es auch, zumindest auf einer Ebene. In der Praxis kann sich die implizite Bedeutung von API je nach dem, worum es gerade geht, ändern. Wenn wir das Akronym entpacken, geht es bei einer API um die Schnittstelle oder den „Vertrag“, über den eine Software mit einer anderen Software interagieren kann. Manchmal konzentriert sich die Diskussion über eine API auf die übergeordneten architektonischen Definitionen; manchmal ist sie sehr detailliert und beschreibt die spezifischen Möglichkeiten, wie Entwickler die API implementieren.

In einigen Büchern und Artikeln über APIs wird der Vergleich verwendet, dass eine API eine Tür ist, wobei die Eigenschaften der API die Tür beschreiben. Dabei kann es sich beispielsweise um eine automatisch geöffnete Lebensmittelgeschäftstür oder um eine extrem sichere Banktresortür handeln. Der Vertrag einer Anwendung – die Eigenschaft der Tür – sollte dazu beitragen, Überlegungen wie diese zu berücksichtigen:

Was macht die API auf hohem Niveau? In unserem Vergleich mit der Tür: Öffnet sie sich, ohne dass der Gast anhalten und etwas berühren muss (Tür eines Lebensmittelgeschäfts), oder kontrolliert sie den Zugang und schützt das, was sich hinter der Tür befindet (Banktresor)?
Welche Nutzlasten (übertragene Daten) müssen unterstützt werden, damit die Software ausgeführt werden kann? Beispiel: Die Software erhält eine Bankkontonummer sowie eine Sicherheitsfreigabe und antwortet mit dem Saldo dieses Bankkontos.
Welche Daten müssen ausgetauscht werden, um diesen Dienst erbringen zu können? Zum Beispiel ist es wichtig, genau zu definieren, was eine gültige Kontonummer und Sicherheitsfreigabe ist, und den Inhalt der Antwort festzulegen. Hier kommt es auf Details an; Unklarheiten können zu Fehlern führen.
Wie lautet die Adresse der Tür? Damit ist in der Regel gemeint, wie der Universal Resource Identifier (URI) für die Anfrage gebildet wird. Wie spricht der Anforderer also eigentlich mit der API?
Welche Protokolle werden zur Kommunikation verwendet? Diese können von bekannten Technologien wie HTTP und FTP bis hin zu speziellen Protokollen wie STOMP und QUIC reichen.
Welche Geschäftsbedingungen muss der API-Benutzer einhalten? Diese können Verschlüsselungsdetails, einen Grenzwert für die Häufigkeit des Aufrufs der APIs oder Rückbelastungsmechanismen für kommerzielle Services umfassen.
Welche Versprechen macht die API? Dazu könnten Service-Level-Garantien für die API gehören, damit eine Anfrage innerhalb einer bestimmten Zeitspanne bestätigt oder ausgeführt wird.

Definition von Messaging in der Anwendungsentwicklung

Während APIs die Bedingungen für das Senden und Empfangen von Serviceanfragen durch Software definieren, ist Messaging der Prozess zum Senden von Informationen von einem System an ein anderes. Das Schlüsselwort hierbei lautet „Prozess“.

Stellen Sie sich das folgendermaßen vor:

Messaging bezieht sich auf den Prozess der Übertragung eines Informationspakets – der Nachricht – vom Serviceanforderer an den Serviceanbieter (oft unter Verwendung einer dritten Partei, die als Broker bekannt ist).

Um einen Vergleich aus der Praxis zu verwenden: Stellen Sie sich ein Unternehmen vor, das eine Textnachricht an einen Kunden sendet. Der Serviceanbieter muss die Telefonnummer des Empfängers kennen, damit der Mobilfunkanbieter die Nachricht übermitteln kann. Die Nutzlast selbst kann jedoch aus der Sicht des Mobilfunkanbieters eine beliebige sein. Der Anbieter muss nicht wissen, ob Ihre Textnachricht auf Englisch, Spanisch oder Japanisch verfasst wurde oder einfach nur ein Emoji umfasst.
Der Begriff Messaging bezieht sich auf alle Vorgänge, die hinter den Kulissen ablaufen, um die Nachricht vom Absender zum Kunden zu bringen.

Sie und Ihr Kunde müssen nicht verstehen, wie der Nachrichtenübermittlungsprozess funktioniert. Sie vertrauen darauf, dass die Netzbetreiber und Smartphone-Hersteller ihre Arbeit richtig gemacht haben. Und ebenso muss der Netzbetreiber die Nutzlast nicht verstehen. Er muss lediglich sicherstellen, dass sie an die richtige Person übermittelt wird und nicht verfälscht oder verzerrt ist.

Es sei noch einmal darauf hingewiesen, dass die meisten Messaging-Plattformen sich nicht um die Nutzlast kümmern, solange diese innerhalb der Grenzen der Technologie liegt. Um zu unserem Vergleich zurückzukehren: Es ist den Smartphone- und Mobilfunkanbietern egal, ob Ihr Text auf Englisch verfasst wurde oder einfach nur ein Emoji umfasst.

Weitere Informationen zur Zusammensetzung von APIs, API-Plattformen und API-Verwaltung.

APIs und Messaging wirken in Unternehmenssystemen zusammen

Unternehmenssoftware-Systeme werden aus mehreren separaten, ausführbaren Prozessen erstellt und erfordern somit Interprozesskommunikation (Interprocess Communication, IPC). Die Kommunikation kann hier komplex sein und viele wechselseitige API-Aufrufe mit einer Menge streng formatierter Daten erfordern, um eine Transaktion durchzuführen. Diese Transaktionen müssen sorgfältig orchestriert und in der richtigen Reihenfolge abgeschlossen werden, um Geschäftsanforderungen zu erfüllen.

Beispiel: Eine Kundenbestellung. Der Prozess muss auf die Kundendatenbank zugreifen, die Bestandsdatenbank, das Buchhaltungssystem, ein Rechnungserstellungssystem und das Kreditkartenabrechnungssystem abfragen, den Bestand und das Kundenkonto anpassen, eine Lageranforderung erstellen und eine Versandanforderung auslösen – all das muss in der richtigen Reihenfolge und korrekt ausgeführt werden.

Früher wurden diese Interaktionen mit einer Form von Shared Storage ausgeführt, wie einem Dateisystem oder einer Datenbank. In modernen Unternehmenssystemen können die Prozesse jedoch direkt miteinander kommunizieren, wodurch der Prozess beschleunigt und Probleme beseitigt werden (z. B. wenn der Bestand für Ihren Auftrag bereits durch frühere Aufträge belegt ist).

Synchrone und asynchrone Verhaltensweisen

Wir können unsere Kommunikation als synchron oder asynchron charakterisieren. Synchrone Kommunikation bedeutet, dass alle an einer Kommunikation beteiligten Parteien anwesend und in der Lage sein müssen, immer wieder zu Wort zu kommen. In unserem Bestellbeispiel müssen die am elektronischen Zahlungsverkehr beteiligten Systeme für eine Interaktion in Echtzeit verfügbar sein. In anderen Fällen kann die Kommunikation asynchron sein, sodass die Parteien der Systeme, die miteinander kommunizieren wollen, nicht zum gleichen Zeitpunkt anwesend sein müssen. So funktioniert der E-Mail-Verkehr. Damit Asynchrone Kommunikation funktioniert, benötigen wir einen Vermittler, um die wechselseitige Weitergabe von Informationen zu ermöglichen.

Diese komplexen Unternehmens-Messaging-Systeme gibt es in verschiedenen Varianten oder Mustern:

Service Bus. Der Service Bus fungiert als Klebstoff zwischen verschiedenen Prozessen und führt eine Orchestrierung zwischen diesen Prozessen aus, z.B. in der oben genannten komplexen Transaktion. Service-Bus-Systeme verfügen in der Regel über Mehrwertfunktionen, wie z. B. die Möglichkeit, Nutzdaten von einem Format in ein anderes zu übersetzen (Englisch in Französisch in unserem Textnachrichten-Vergleich), Nachrichten auf der Grundlage des Nachrichteninhalts weiterzuleiten oder sogar einige Entscheidungen auf der Grundlage des Status der komplexen Transaktion zu treffen. Zum Beispiel: Die Aufgaben A und B können parallel ausgeführt werden. Führen Sie Aufgabe C aus, sobald Aufgabe B erfolgreich abgeschlossen wurde. Wenn Aufgabe B fehlschlägt, führen Sie Aufgabe D aus. Wenn Aufgabe D fehlschlägt, soll ein Mensch eingreifen.

Service-Bus-Messaging wird manchmal als Smart Pipe bezeichnet, da die zusätzliche Intelligenz in Bezug auf die Weiterleitung und Planung der Nachrichtenübermittlung in der Pipeline zwischen den Anbietern und Verbrauchern zum Tragen kommt. Das wird außerdem als Orchestrierung bezeichnet.

Der Nachrichtenanbieter ruft den Service Bus auf, der eine Nachricht bereitstellt. Der Service Bus leitet dann die Nachricht an die Verbraucher weiter. Während der Weiterleitung kann die Nachricht einer Transformationslogik und Filterung unterliegen.

Ein synonymer Begriff für Service Bus ist der Nachrichtenbus. Als sich diese Technologien erstmals zu serviceorientierten Architekturlösungen (SOA) entwickelten, gab es einige Unterschiede zwischen Nachrichtenbussen und Servicebussen. Heute gibt es keine echten Unterschiede mehr. Es wird zunehmend sogar die kürzere Bezeichnung „Bus“ verwendet.
Webservices: Im weitesten Sinne des Begriffs stellen Webservices eine direkte synchrone Kommunikation zwischen zwei Prozessen dar, die üblicherweise die TCP- und HTTP-Protokolle (oder Variationen wie HTTPS und HTTP/2) verwendet. Verbraucher und Client werden als Point-to-Point-Verbindungen realisiert (obwohl es üblich ist, dass die Anbieterseite mehrere gleichzeitige Kundenverbindungen unterstützt). Zwischen den beiden Prozessen können Proxys (von Netzwerk-Firewalls bis hin zu API-Gateways und Web-Caches) und Netzwerk-Zwischenstationen (Switches und Router) stehen, die aber weder dem Anbieter noch dem Verbraucher bewusst sind.
Der Nachrichtenanbieter kommuniziert direkt mit dem Verbraucher. Der Übertragungsprozess ist von der Verfügbarkeit beider Parteien abhängig.
Message Broker:Message Broker sind Vermittler zwischen dem Nachrichtenanbieter und dem Nachrichtenverbraucher und haben Gemeinsamkeiten sowohl bei Service Buses als auch bei Webservices.

Broker befinden sich zwischen dem Absender und den Nachrichtenempfängern. Sie erhalten die Nachricht, die übermittelt wird, und speichern sie, bis die Empfänger sie abrufen. Das bedeutet, dass die Nachricht übermittelt werden kann, ohne dass man sich Gedanken über die unmittelbare Verfügbarkeit des Empfängers machen muss. Infolgedessen wird diese Art von Kommunikation oft als asynchron oder „fire and forget“ bezeichnet, weil Sie sicher sein können, dass die Nachricht irgendwann zugestellt wird, solange der Broker funktionsfähig bleibt.

Die Ähnlichkeit mit Webservices ergibt sich aus der Tatsache, dass die Verbindung zwischen Client und Broker als Point-to-Point-Verbindung dargestellt wird; der Message Broker ist funktionell unsichtbar.

Die Ähnlichkeit mit einem Service Bus ergibt sich aus der Tatsache, dass der Broker einen Mehrwert-Service anbietet, indem er die empfangenen Nachrichten speichern kann, bis die Empfänger verfügbar sind. Im Gegensatz zu einem robusteren Service Bus verfügt ein Message Broker nur über minimale Intelligenz, um einfache Dinge zu verstehen, wie z. B. zu wissen, welche Empfänger eine bestimmte Nachricht erhalten möchten und was zu tun ist, wenn der Empfänger die Nachricht nicht rechtzeitig abruft.

Ein vermittelter Kommunikationsstil wird auch Dumb Pipe genannt. Da die Broker nur über minimale Intelligenz verfügen, müssen die Endpunkte verstehen, was erforderlich ist, wenn eine Nachricht gesendet oder empfangen werden muss. Dieser Stil wird als Choreografie (im Gegensatz zur intelligenteren Orchestrierung eines Service Bus) bezeichnet.

Der Nachrichtenanbieter sendet seine Nachricht an den Broker. Der Broker speichert die Nachricht dann, bis die Verbraucher entweder eine Nachricht angefordert haben oder die Nachricht empfangen können. Der Anbieter ist nicht vom Verbraucher abhängig.

Die Rolle des Streaming im Unternehmens-Messaging

Für diese Diskussion kann Streaming als eine eher besondere Form der Nachrichtenübermittlung angesehen werden, obwohl einige Streaming-Technologien ein Element der Datenverarbeitung unterstützen können. Streaming beschreibt in diesem Zusammenhang das Senden eines kontinuierlichen Stroms von Ereignissen durch die IPC-Technologie an dieselben Ziele, unabhängig davon, ob Webdienste oder Message Broker die Kommunikation durchführen. (Sehr selten sind Service Buses beteiligt, da die Datenmenge zu groß ist und zu schnell fließt, als dass die zusätzliche Intelligenz eines Service Bus benötigt wird.)

Neben dem kontinuierlichen Datenfluss in einem Stream wird beim Streaming in der Regel eine nahezu echtzeitfähige oder latenzarme Verbindung erwartet. Das ist keine Überraschung, wenn man bedenkt, dass Dienste wie Netflix traditionell als Video-Streaming bezeichnet werden. Man will ja nicht, dass Video-Inhalte gestoppt und erneut gestartet werden, während neue Video-Bits vom Anbieter übermittelt werden oder während ein Message Broker das Video von einem Format in ein anderes umwandelt.

Häufige Technologien für Webservice-Streaming sind WebSockets, gRPC-Streams und GraphQL-Abonnements. Wenn es um vermittelte Messaging-Streams geht (mit Technologien wie Kafka), können Sie manchmal die Arbeitsweise des Brokers nutzen, um einen „Ausschnitt“ der übertragenen Ereignisse zu betrachten. Auf diese Weise erhalten Sie wertvolle Erkenntnisse, einschließlich Informationen über den Stream selbst – deshalb der Begriff Streaming Analytics.

Während die in Streaminganalysen angewendete Logik komplex sein kann, führt der Message Broker keine Entscheidungs- oder Nachrichtenmanipulation durch. Deshalb wird der Broker immer noch als dumm bezeichnet. Diese Arten von Streaminganalysefunktionen werden häufig mit Technologien wie Kafka Streams implementiert.

API- und Messaging-Branchenstandards

APIs und Messaging-Systeme sind einfach zu beschreiben, aber sehr komplex in ihren Details und technischen Eigenschaften. Es gibt einfach keinen Raum für Mehrdeutigkeit, was zu einem echten Bedarf an genauen Branchenstandards und Dokumentationen sowie idealerweise der besten Anwendung dieser Standards führt.

Die Entwicklung in diesem Bereich, insbesondere bei APIs, läuft seit mehr als zehn Jahren. Die Branche hat die OpenAPI-Spezifikation für REST-basierte APIs übernommen, die eine Form von Webservices und wahrscheinlich die am häufigsten verwendeten Arten von APIs in moderner Unternehmenssoftware sind.

Bei APIs (und Streaming) gibt es eine Reihe zusätzlicher Standards zum Definieren und Beschreiben von Aspekten der Nachrichten und ihrer Übertragung. Dazu gehören Protokollpuffer (auch Protobuf genannt und mit gRPC verwendet) und in jüngerer Zeit GraphQL, JSON Schema und YAML.

Im Bereich der asynchronen Nachrichtenübermittlung wurde in den letzten Jahren erfolgreich an einer Definition namens AsyncAPI gearbeitet, die Ideen von OpenAPI und anderen fortschreitenden Standards übernommen hat, um die zahlreichen Anforderungen an die Nachrichtenübermittlung zu erfüllen.

Moderne verteilte Anwendungen sind als eine Sammlung von Diensten implementiert, bei denen es sich um separate Software handelt, die manchmal auf denselben Servern läuft, andere Male aber auch nicht. APIs bieten diesen Softwarekomponenten die Möglichkeit, miteinander zu kommunizieren, um Dienste anzufordern oder Informationen auszutauschen. Messaging-Systeme bieten die Infrastruktur, um die asynchrone Kommunikation zu erleichtern und intelligente Vermittler für API-Aufrufe bereitzustellen, die sehr einfach (z. B. Smartphone-Textnachrichten) oder extrem komplex (z. B. Orchestrierung für komplexe mehrstufige Geschäftstransaktionen) sein können. Ganz zu schweigen von den verteilten Services, die über APIs direkt miteinander kommunizieren. Glücklicherweise ermöglichen die sich ständig weiterentwickelnden Techniken und Normen die Verwendung von APIs in allen Bereichen, von Datenbankaufrufen bis hin zum Medien-Streaming. Da diese APIs und Messaging-Standards immer besser werden, wird auch der Übergang zu modernen, verteilten Softwarearchitekturen immer schneller, einfacher und sicherer.