Die Unterschiede zwischen synchronen und asynchronen APIs

Die API (Application Programming Interface) funktionieren nach einem Anfrage-Antwort-Modell: Bei einem API-Aufruf sendet der Client eine Anfrage an den Server, und dieser antwortet, indem er die angeforderten Daten oder eine Nachricht bereitstellt. Dieses allgemeine Schema kann in zwei Ausführungsmodi umgesetzt werden: synchron und asynchron. 

Der Unterschied zwischen diesen beiden Modellen ist nicht nur theoretisch, sondern hat großen Einfluss auf die Entwicklung skalierbarer und effizienter Systeme. Daher ist die korrekte Implementierung synchroner und asynchroner Interaktionsmechanismen ein grundlegendes Merkmal jeder modernen Anwendungsarchitektur.

Synchrone APIs: Was sie sind und wie sie funktionieren

Bei einer synchronen API erfolgt die Kommunikation in Echtzeit: Der Client sendet eine Anfrage an den Server und wartet, bis er eine Antwort erhält. Während dieser Zeit kann der Client keine anderen Operationen ausführen oder neue Anfragen im selben Thread senden; deshalb spricht man auch von einem „blockierenden“ Mechanismus.

Dieser API-Typ ist ideal für schnelle Operationen, wie das Abrufen von Geocoding-Daten für die Satellitennavigation oder das Aktualisieren einer gemeinsamen Datenbank. Die Antwort des Servers erfolgt praktisch sofort und enthält in der Regel die angeforderten Daten oder die Bestätigung, dass ein bestimmter Befehl ausgeführt wurde, z. B. das Löschen einer Ressource oder das Weiterleiten einer Nachricht. 

Synchrone APIs sind sehr häufig in Web-Microservices, da sie eine sofortige Rückmeldung ermöglichen und einfach zu implementieren sind. Andererseits erfordert dieses Kommunikationsmodell, dass der Client auf die Antwort des Servers wartet, bevor er etwas anderes tun kann. Das bedeutet, dass es nur geeignet ist, wenn die Verarbeitung der Antwort wenige Sekunden dauert. In einigen Anwendungen, wie beim Hochladen und Analysieren großer Videodateien oder beim Erstellen eines Finanzberichts, kann dieser Mechanismus ineffizient werden und die Skalierbarkeit des Systems beeinträchtigen.

Was sind asynchrone APIs?

Im Gegensatz zu synchronen APIs arbeiten asynchrone APIs nach einem Anfrage-Akzeptieren-Benachrichtigungs-Modell: Wenn der Client eine Anfrage sendet, antwortet der Server mit der Bestätigung, dass er die Operation angenommen hat. Der typische Antwortcode ist „202 Accepted“, und die Antwort enthält normalerweise eine ID, die verwendet wird, um das Endergebnis abzurufen, sobald es fertig ist. Zu diesem Zeitpunkt kann der Client andere Anfragen verarbeiten (dies wird als „nicht blockierender“ Mechanismus bezeichnet). 

Wenn der Server die Antwort verarbeitet hat, sendet er sie an den Client. Dies kann auf zwei Arten geschehen:

• Polling: Der Client fragt den Status des Servers regelmäßig ab, bis er die Antwort findet (Pull-Modell);
• Callback / Webhook: Wenn die Antwort fertig ist, ruft der Server eine Client-URL auf, um ihn über den Abschluss der Operation zu informieren (Push-Modell).

Asynchrone APIs sind unverzichtbar in Szenarien, in denen längere Antwortzeiten zu erwarten sind, wie z. B. bei der Verarbeitung von Videos oder Dokumenten. Der Hauptvorteil dieser architektonischen Wahl ist die vollständige Abwesenheit von Wartezeiten, wodurch Rechen- und Netzressourcen optimal genutzt werden können. Andererseits sind asynchrone Abläufe komplexer zu konfigurieren, da sie unter anderem eine Benachrichtigungsverwaltung erfordern.

Unterschiede zwischen synchronen und asynchronen APIs

Um die Unterschiede zwischen synchronen und asynchronen APIs zusammenzufassen, kann man sagen, dass sie folgende Aspekte betreffen:

• Arbeitsablauf: Während synchrone APIs den Client blockieren, bis die Antwort eintrifft, geben asynchrone APIs ihm eine Referenz, um die Antwort später „abzuholen“, und entlasten ihn sofort;
• Anwendungsfälle: Synchrone APIs eignen sich für kurze und schnelle Operationen, während asynchrone APIs bei Prozessen, die mehr als ein paar Millisekunden dauern, oder bei Aufgaben mit Warteschlangen vorzuziehen sind;
• Antwortzustellung: Bei synchronen APIs wird die Antwort sofort geliefert, bei asynchronen erfolgt die Zustellung später über Benachrichtigungsmechanismen (Polling oder Callback);
• Komplexität: Asynchrone APIs sind komplexer zu implementieren, da sie den Status der Operation über die Zeit verwalten müssen und Benachrichtigungsmechanismen erfordern, die mit dem Client abgestimmt werden müssen (z. B. Polling-Zyklen oder ein Callback-Endpunkt).

Viele moderne Anwendungen verwenden hybride Architekturen, bei denen synchrone und asynchrone APIs je nach Bedarf kombiniert werden. In jedem E-Commerce-System verwenden beispielsweise Vorgänge wie Warenkorbprüfung und Zahlungsautorisierung synchrone Kommunikation, während nachfolgende Vorgänge wie Bestellbestätigungs-E-Mails und Rechnungserstellung asynchron erfolgen.

Wann man synchrone und asynchrone APIs verwenden sollte

Die Wahl zwischen synchronen und asynchronen APIs hängt im Wesentlichen von der Ausführungszeit der Operation und dem Bedarf an einer sofortigen Antwort durch den Client ab. Wenn der Client zum Beispiel die Antwort benötigt, bevor er fortfährt, ist synchrone Kommunikation sinnvoll. Typische Fälle sind Authentifizierungsprozesse, bei denen der Server die Anmeldedaten des Benutzers sofort überprüfen muss, sowie das Abrufen von Echtzeitdaten, die z. B. für das Laden von Bildern oder das Abrufen von Produktmetadaten auf einer E-Commerce-Seite erforderlich sind. 

Die asynchronen APIs sind die offensichtliche Wahl für alle Operationen, deren Verarbeitung länger als ein paar Millisekunden dauert. Häufige Beispiele sind die Verarbeitung großer Dateien, deren Konvertierung oder Import im Hintergrund erfolgen kann, während der Client andere Aufgaben ausführt, sowie der Massenversand von E-Mails, der sofort angenommen und über die Zeit verarbeitet wird.

Wenn die Verarbeitung im Hintergrund erfolgen kann, ohne den Client zu blockieren, und keine sofortige Rückmeldung erforderlich ist, ist eine asynchrone Architektur zweifellos die effizienteste Wahl – insbesondere in Umgebungen, die viele Ressourcen verwalten, wie z. B. Handelsplattformen, bei denen die Aggregation historischer Daten Zeit erfordert, aber den Echtzeitbetrieb nicht blockieren darf.