Echtzeit- und ereignisgetriebene APIs: WebSockets, SSE, Pub/Sub und AsyncAPI

Klassische REST-APIs funktionieren nach dem Muster: Der Client fragt, der Server antwortet. Für Daten, die jederzeit serverseitig entstehen (neue Nachricht, Sensorwert, Kursänderung), ist das ineffizient, weil der Client ständig nachfragen (pollen) müsste. Vier Bausteine lösen das auf unterschiedliche Weise.

WebSockets öffnen laut MDN eine zweiseitige, interaktive Kommunikationssitzung zwischen Browser und Server. Man kann Nachrichten senden und Antworten empfangen, ohne den Server pollen zu müssen. Die Verbindung startet als HTTP und wird über einen Handshake hochgestuft; dabei sind Header wie Sec-WebSocket-Key, Sec-WebSocket-Accept, Sec-WebSocket-Version und Sec-WebSocket-Protocol beteiligt. Das Protokoll ist in RFC 6455 spezifiziert. Geeignet für Chats, kollaboratives Arbeiten und Spiele, also alles, wo beide Seiten jederzeit senden.

Server-Sent Events (SSE) sind laut MDN eine Einbahnverbindung: Der Client kann darüber keine Ereignisse an den Server senden. Im Browser übernimmt das die EventSource-Schnittstelle; der Server antwortet mit dem MIME-Typ text/event-stream. Fällt die Verbindung aus, wird sie standardmäßig automatisch neu aufgebaut. SSE ist schlanker als WebSockets und ideal, wenn nur der Server pushen muss (Live-Ticker, Benachrichtigungen, Fortschrittsanzeigen).

Ereignisgetriebene bzw. nachrichtenbasierte Architektur entkoppelt Sender und Empfänger über Publish/Subscribe und einen Message Broker. Producer veröffentlichen Nachrichten zu Themen (Topics/Channels), Consumer abonnieren sie, ohne einander direkt zu kennen. Typische Protokolle und Systeme:

• MQTT: leichtgewichtiges Pub/Sub-Protokoll, verbreitet im IoT-Umfeld.
• AMQP: nachrichtenorientiertes Protokoll für zuverlässige Warteschlangen.
• Apache Kafka: verteilte Plattform für hohe Durchsatzraten und dauerhafte Ereignis-Logs.

Webhooks drehen den Aufruf um: Statt dass der Client fragt, ruft der Server bei einem Ereignis eine vom Client hinterlegte URL per HTTP auf (HTTP-Callback). Das eignet sich für seltene, ereignisbasierte Benachrichtigungen zwischen Systemen, etwa Zahlungsbestätigungen oder Git-Pushes.

AsyncAPI ist die Spezifikation, um solche Schnittstellen zu beschreiben. Die MDN-Doku nennt sie ausdrücklich als Werkzeug für WebSocket-basierte APIs und stellt sie OpenAPI gegenüber: So wie OpenAPI REST-APIs beschreibt, beschreibt AsyncAPI ereignisgetriebene Architekturen auf Basis von Protokollen wie WebSocket. Die offizielle Doku fasst die Kernkonzepte (Server, Producer, Consumer, Channel, Application, Protocol, Message) als Bausteine dieser Beschreibung zusammen.

Einordnung für die Auswahl:

• Beide Seiten senden in Echtzeit: WebSockets.
• Nur der Server pusht an Browser: SSE (einfacher, mit Auto-Reconnect).
• Systeme entkoppeln, viele Empfänger, IoT: Pub/Sub mit Broker (MQTT, AMQP, Kafka).
• Punktuelle Server-zu-Server-Benachrichtigung: Webhooks.
• Solche Async-Schnittstellen dokumentieren: AsyncAPI.

// Server-Sent Events im Browser (MDN: EventSource)
const evtSource = new EventSource("sse-demo.php");

evtSource.onmessage = (event) => {
  console.log("Neue Server-Nachricht:", event.data);
};

evtSource.onerror = (err) => {
  console.error("EventSource fehlgeschlagen:", err);
};

// Serverseitig (PHP): Antwort als text/event-stream
// header("Content-Type: text/event-stream");
// header("Cache-Control: no-cache");
// echo "data: pong\n\n";

Eine einseitige SSE-Verbindung: Der Client empfängt nur, der Server pusht mit MIME-Typ text/event-stream.

Quellen

• WebSocket API (WebSockets) MDN Web Docs
• Using server-sent events MDN Web Docs
• Concepts Overview - AsyncAPI AsyncAPI Initiative