Warum wurden server-sent Ereignisse in HTML5 eingeführt?

Um einen unidirektionalen Kommunikationskanal zwischen Server und Client zu implementieren. Der Server kann Daten an den Client zu jeder Zeit nach Verbindungsherstellung senden.

Wichtige Merkmale und Vorteile:

• Effizienz: Es wird eine normale HTTP-Verbindung verwendet, die die Overheads im Vergleich zum Polling minimiert.
• Einfachheit: Die API für serverseitige Ereignisse (SSE) ist einfacher zu verwenden als WebSockets für unidirektionale Kommunikation.
• Automatisches Wiederverbinden: Der Browser versucht automatisch, die Verbindung bei Unterbrechung wiederherzustellen.
• Unterstützung von Datentypen: Es werden Textdaten im Format text/event-stream unterstützt.
• Browser-Unterstützung: Wird von modernen Browsern breit unterstützt.

Anwendungen:

• Echtzeit-Updates von Nachrichten-Feeds.
• Benachrichtigungen über Ereignisse (z.B. neue Nachrichten).
• Überwachung von Daten in Echtzeit (z.B. Börsenkurse).
• Fortschrittsanzeige bei langen Aufgaben.

Dies ist eine Alternative zum traditionellen Polling, bei dem der Client regelmäßig beim Server nach Updates fragt. Im Gegensatz zu WebSockets ist SSE unidirektional, was die Anwendung vereinfacht, wenn Daten nur vom Server zum Client übertragen werden.

Beispiel auf der Client-Seite (JavaScript):

const eventSource = new EventSource('/events'); // URL zum Empfang von Server-Ereignissen

eventSource.onmessage = function(event) {
  // Verarbeitung der empfangenen Daten
  console.log('Nachricht empfangen:', event.data);
};

eventSource.onerror = function(error) {
  // Fehlerbehandlung bei Verbindung
  console.error('Server-Sent Events Fehler:', error);
};

eventSource.addEventListener('customEvent', function(event) {
  // Verarbeitung eines benutzerdefinierten Ereignisses vom Typ 'customEvent'
  console.log('Benutzerdefiniertes Ereignis empfangen:', event.data);
});

Beispiel für das Datenformat auf der Serverseite:

event: customEvent
data: {"message": "Hallo!"}

data: Einfache Textnachricht

id: 123 // Ereignis-ID, wird für automatische Wiederverbindung verwendet

retry: 5000 // Verzögerung vor der nächsten Wiederverbindung in Millisekunden