WebSocket vs. Server-Sent Events: Was ist besser für Echtzeit-APIs?

TL;DR

Verwenden Sie Server-Sent Events (SSE) für unidirektionale Server-zu-Client-Updates wie Benachrichtigungen und Live-Feeds. Verwenden Sie WebSocket für bidirektionale Kommunikation wie Chat und Gaming. SSE ist einfacher und funktioniert über HTTP. WebSocket ist komplexer, unterstützt aber bidirektionale Nachrichtenübermittlung. Die moderne PetstoreAPI implementiert beide für verschiedene Echtzeit-Anwendungsfälle.

Einführung

Sie benötigen Echtzeit-Updates in Ihrer API. Der Status eines Haustiers ändert sich von „verfügbar“ zu „adoptiert“ – Clients müssen dies sofort wissen. Verwenden Sie WebSocket oder Server-Sent Events (SSE)?

Die meisten Entwickler greifen standardmäßig zu WebSocket, weil es „leistungsfähiger“ ist. Doch SSE ist oft die bessere Wahl. Es ist einfacher, funktioniert über Standard-HTTP und handhabt die Wiederverbindung automatisch. WebSocket fügt eine Komplexität hinzu, die Sie möglicherweise nicht benötigen.

Die moderne PetstoreAPI implementiert beide Protokolle. SSE für Haustier-Status-Updates und Bestellbenachrichtigungen. WebSocket für Live-Auktionsgebote und Echtzeit-Chat. Jedes Protokoll dient unterschiedlichen Anwendungsfällen.

💡

Wenn Sie Echtzeit-APIs entwickeln oder testen, unterstützt Apidog sowohl SSE- als auch WebSocket-Tests. Sie können Ereignisströme testen, Nachrichtenformate validieren und Wiederverbindungsszenarien simulieren.

Schaltfläche

In diesem Leitfaden erfahren Sie die Unterschiede zwischen SSE und WebSocket, sehen reale Beispiele aus der modernen PetstoreAPI und entdecken, wann Sie welches Protokoll verwenden sollten.

Was sind Server-Sent Events (SSE)?

SSE ist ein HTTP-basiertes Protokoll zum Streamen von Ereignissen vom Server zum Client.

Wie SSE funktioniert

Der Client öffnet eine Verbindung und empfängt Ereignisse, sobald sie eintreten:

const eventSource = new EventSource('https://petstoreapi.com/v1/pets/notifications');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet update:', data);
};

eventSource.addEventListener('adoption', (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet adopted:', data.petId);
});

Der Server sendet Ereignisse:

GET /v1/pets/notifications
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: adoption
data: {"petId":"019b4132","userId":"user-456"}

event: status-change
data: {"petId":"019b4127","status":"AVAILABLE"}

SSE-Funktionen

1. Unidirektionale Kommunikation

Der Server sendet an den Client. Der Client kann über die SSE-Verbindung keine Nachrichten zurücksenden (kann aber reguläre HTTP-Anfragen verwenden).

2. Basiert auf HTTP

Verwendet Standard-HTTP. Funktioniert durch Proxys, Firewalls und CDNs.

3. Automatische Wiederverbindung

Wenn die Verbindung abbricht, stellt der Browser automatisch die Verbindung wieder her.

4. Ereignis-IDs zur Fortsetzung

Der Server kann Ereignis-IDs senden. Der Client setzt vom zuletzt empfangenen Ereignis fort:

id: 123
event: adoption
data: {"petId":"019b4132"}

id: 124
event: status-change
data: {"petId":"019b4127"}

Bei Trennung sendet der Client den Header Last-Event-ID: 124, um fortzufahren.

5. Einfaches Protokoll

Textbasiertes Format. Einfach mit curl zu debuggen:

curl -N -H "Accept: text/event-stream" \
  https://petstoreapi.com/v1/pets/notifications

SSE-Einschränkungen

1. Nur unidirektional

Der Client kann über SSE keine Nachrichten senden. Für die Client-Server-Kommunikation sind separate HTTP-Anfragen erforderlich.

2. Nur Text

SSE sendet Text. Binärdaten müssen base64-kodiert sein.

3. Browser-Verbindungslimits

Browser begrenzen SSE-Verbindungen pro Domain (typischerweise 6). Dies ist für die meisten Apps kein Problem.

4. Keine integrierte Komprimierung

HTTP-Komprimierung funktioniert, aber keine Komprimierung auf Protokollebene wie bei WebSocket.

Was ist WebSocket?

WebSocket ist ein Vollduplex-Bidirektionalprotokoll über eine persistente Verbindung.

Wie WebSocket funktioniert

Client und Server können jederzeit Nachrichten senden:

const ws = new WebSocket('wss://petstoreapi.com/auctions/019b4132');

// Send message to server
ws.send(JSON.stringify({
  type: 'bid',
  amount: 500
}));

// Receive messages from server
ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Auction update:', data);
};

ws.onclose = () => {
  console.log('Connection closed');
  // Manual reconnection logic needed
};

Der Server kann jederzeit senden:

{"type":"bid","userId":"user-456","amount":550}
{"type":"outbid","newAmount":550}

Der Client kann jederzeit senden:

{"type":"bid","amount":600}
{"type":"watch","petId":"019b4132"}

WebSocket-Funktionen

1. Bidirektional

Sowohl Client als auch Server können jederzeit Nachrichten senden. Echte Zwei-Wege-Kommunikation.

2. Geringe Latenz

Persistente Verbindung. Kein HTTP-Overhead pro Nachricht. Ideal für Gaming, Chat, Live-Zusammenarbeit.

3. Binärdaten-Unterstützung

Kann Binärdaten direkt senden. Keine Base64-Kodierung erforderlich.

4. Benutzerdefiniertes Protokoll

Verwendet ws:// oder wss:// (sicher). Nach dem initialen Handshake kein HTTP mehr.

5. Rahmenbasiert

Nachrichten werden gerahmt. Kann Teillnachrichten senden und wieder zusammensetzen.

WebSocket-Einschränkungen

1. Komplexe Einrichtung

Erfordert einen WebSocket-Server. Komplexer als HTTP-Endpunkte.

2. Manuelle Wiederverbindung

Keine automatische Wiederverbindung. Sie müssen eine Wiederholungslogik implementieren.

3. Proxy-Probleme

Einige Unternehmens-Proxys blockieren WebSocket. HTTP-Proxys verstehen ws:// nicht.

4. Zustandsbehaftet

Der Server muss Verbindungen verfolgen. Schwieriger zu skalieren als zustandsloses HTTP.

5. Keine HTTP-Funktionen

Nach dem Handshake können keine HTTP-Caching, Statuscodes oder Standard-Header verwendet werden.

Direkter Vergleich

Funktion	SSE	WebSocket
Richtung	Server → Client	Bidirektional
Protokoll	HTTP	Benutzerdefiniert (ws://)
Wiederverbindung	Automatisch	Manuell
Browser-Unterstützung	Alle modernen	Alle modernen
Proxy-freundlich	Ja	Manchmal
Komplexität	Einfach	Komplex
Binärdaten	Nein (nur Text)	Ja
Latenz	Gering	Sehr gering
Skalierbarkeit	Hoch (zustandslos)	Mittel (zustandsbehaftet)
Anwendungsfall	Benachrichtigungen, Feeds	Chat, Gaming, Zusammenarbeit

Wie die moderne PetstoreAPI beide nutzt

Die moderne PetstoreAPI implementiert sowohl SSE als auch WebSocket für verschiedene Szenarien.

SSE für Haustier-Updates

Endpunkt: GET /v1/pets/notifications

const events = new EventSource(
  'https://petstoreapi.com/v1/pets/notifications?userId=user-456'
);

events.addEventListener('adoption', (e) => {
  const data = JSON.parse(e.data);
  showNotification(`${data.petName} was adopted!`);
});

events.addEventListener('status-change', (e) => {
  const data = JSON.parse(e.data);
  updatePetStatus(data.petId, data.status);
});

Server-Implementierung:

app.get('/v1/pets/notifications', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const userId = req.query.userId;

  // Subscribe to pet updates
  const subscription = petUpdates.subscribe(userId, (event) => {
    res.write(`event: ${event.type}\n`);
    res.write(`data: ${JSON.stringify(event.data)}\n\n`);
  });

  req.on('close', () => {
    subscription.unsubscribe();
  });
});

Anwendungsfälle:

Haustier-Statusänderungen (verfügbar → adoptiert)
Bestellbenachrichtigungen (aufgegeben, versandt, geliefert)
Bestandsaktualisierungen
Preisänderungen

WebSocket für Live-Auktionen

Endpunkt: wss://petstoreapi.com/auctions/{auctionId}

const ws = new WebSocket('wss://petstoreapi.com/auctions/019b4132');

// Place bid
function placeBid(amount) {
  ws.send(JSON.stringify({
    type: 'bid',
    amount
  }));
}

// Receive updates
ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);

  switch (msg.type) {
    case 'bid':
      updateCurrentBid(msg.amount, msg.userId);
      break;
    case 'outbid':
      showOutbidNotification(msg.newAmount);
      break;
    case 'auction-end':
      showAuctionResult(msg.winner);
      break;
  }
};

Server-Implementierung:

wss.on('connection', (ws, req) => {
  const auctionId = req.params.auctionId;
  const auction = auctions.get(auctionId);

  ws.on('message', (data) => {
    const msg = JSON.parse(data);

    if (msg.type === 'bid') {
      const result = auction.placeBid(msg.userId, msg.amount);

      // Broadcast to all participants
      auction.participants.forEach(participant => {
        participant.send(JSON.stringify({
          type: 'bid',
          userId: msg.userId,
          amount: msg.amount
        }));
      });
    }
  });
});

Anwendungsfälle:

Live-Auktionsgebote
Echtzeit-Chat mit Support
Kollaborative Haustierpflegeplanung
Live-Bestandsaktualisierungen während des Verkaufs

Testen von Echtzeit-APIs mit Apidog

Apidog unterstützt das Testen von sowohl SSE- als auch WebSocket-APIs.

Testen von SSE

1. SSE-Anfrage erstellen:

GET https://petstoreapi.com/v1/pets/notifications
Accept: text/event-stream

2. Ereignisse validieren:

Ereignistypen prüfen
JSON-Nutzdaten validieren
Wiederverbindungsverhalten testen
Ereignis-IDs überprüfen

3. Testszenarien:

Verbindungsabbrüche
Server-Neustarts
Ereignisreihenfolge
Fortsetzung vom letzten Ereignis

Testen von WebSocket

1. WebSocket-Verbindung erstellen:

wss://petstoreapi.com/auctions/019b4132

2. Testnachrichten senden:

{"type":"bid","amount":500}
{"type":"watch","petId":"019b4132"}

3. Antworten validieren:

Nachrichtenformate prüfen
Bidirektionalen Fluss testen
Verbindungsbehandlung überprüfen
Fehlerszenarien testen

4. Testszenarien:

Mehrere gleichzeitige Verbindungen
Nachrichtenreihenfolge
Verbindungs-Timeouts
Wiederverbindungslogik

Wann man welches verwendet

SSE verwenden, wenn:

Unidirektionale Updates - Server sendet an den Client, Client muss nicht zurücksenden
Einfache Einrichtung - Standard-HTTP-Infrastruktur nutzen möchten
Automatische Wiederverbindung - Keine Wiederholungslogik implementieren möchten
Proxy-freundlich - Durch Unternehmens-Firewalls funktionieren muss
Benachrichtigungen - Status-Updates, Alarme, Live-Feeds

Beispiele:

Benachrichtigungen über Tieradoptionen
Bestellstatus-Updates
Bestandsänderungen
Preisalarme
Nachrichten-Feeds

WebSocket verwenden, wenn:

Bidirektional - Sowohl Client als auch Server häufig Nachrichten senden
Geringe Latenz kritisch - Gaming, Echtzeit-Zusammenarbeit
Binärdaten - Bilder, Audio, Video senden
Benutzerdefiniertes Protokoll - Volle Kontrolle über das Nachrichtenformat benötigen
Hohe Nachrichten-Frequenz - Hunderte von Nachrichten pro Sekunde

Beispiele:

Live-Auktionsgebote
Echtzeit-Chat
Multiplayer-Spiele
Kollaboratives Bearbeiten
Live-Video-Streaming

Verwenden Sie WebSocket nicht nur, weil:

❌ „Es ist fortschrittlicher“ - Komplexität ohne Nutzen

❌ „Jeder benutzt es“ - SSE ist oft einfacher

❌ „Es ist schneller“ - SSE ist für die meisten Anwendungsfälle schnell genug

❌ „Es ist bidirektional“ - Benötigen Sie wirklich bidirektionale Kommunikation?

Fazit

SSE und WebSocket ermöglichen beide Echtzeitkommunikation, sind aber für unterschiedliche Szenarien konzipiert. SSE brilliert bei unidirektionalen Server-zu-Client-Updates mit automatischer Wiederverbindung und HTTP-Kompatibilität. WebSocket glänzt bei bidirektionaler Kommunikation mit geringer Latenz.

Die moderne PetstoreAPI zeigt, wie beide Protokolle effektiv eingesetzt werden können. SSE für Benachrichtigungen und Status-Updates. WebSocket für Live-Auktionen und Chat. Wählen Sie basierend auf Ihrem Anwendungsfall, nicht danach, welches Protokoll „besser“ erscheint.

Testen Sie Ihre Echtzeit-APIs mit Apidog, um sicherzustellen, dass sowohl SSE- als auch WebSocket-Implementierungen in verschiedenen Szenarien korrekt funktionieren.

FAQ

Kann SSE durch Unternehmens-Firewalls funktionieren?

Ja. SSE verwendet Standard-HTTP, daher funktioniert es durch HTTP-Proxys und Firewalls. WebSocket verwendet ein benutzerdefiniertes Protokoll, das von einigen Proxys blockiert wird.

Ist WebSocket schneller als SSE?

WebSocket hat eine etwas geringere Latenz (kein HTTP-Overhead pro Nachricht), aber für die meisten Anwendungen ist der Unterschied vernachlässigbar. SSE ist schnell genug für Benachrichtigungen, Feeds und Status-Updates.

Wie handhaben Sie die SSE-Wiederverbindung?

Der Browser handhabt die Wiederverbindung automatisch. Senden Sie Ereignis-IDs vom Server, und der Client setzt vom zuletzt empfangenen Ereignis unter Verwendung des Headers Last-Event-ID fort.

Können Sie SSE mit mobilen Apps verwenden?

Ja. iOS und Android unterstützen SSE über native HTTP-Clients oder Bibliotheken. SSE funktioniert überall dort, wo HTTP funktioniert.

Was ist die maximale SSE-Verbindungszeit?

Es gibt keine feste Grenze. SSE-Verbindungen können unbegrenzt offen bleiben. Einige Proxys oder Load Balancer können Timeouts haben (typischerweise 30-60 Sekunden), aber der Browser stellt automatisch die Verbindung wieder her.

Kann WebSocket Binärdaten senden?

Ja. WebSocket unterstützt sowohl Text- als auch Binär-Frames. Sie können Bilder, Audio oder beliebige Binärdaten ohne Base64-Kodierung senden.

Wie viele SSE-Verbindungen kann ein Browser haben?

Browser begrenzen SSE-Verbindungen pro Domain (typischerweise 6). Dies ist selten ein Problem – die meisten Apps benötigen nur 1-2 SSE-Verbindungen.

Benötigt man einen speziellen Server für SSE?

Nein. Jeder HTTP-Server kann SSE verarbeiten. Stellen Sie einfach die korrekten Header ein (Content-Type: text/event-stream) und halten Sie die Verbindung offen.