Server-sent events
Server-sent events carry text notifications from server to client over HTTP, for example about the progress of a background job.
Server-sent events, or SSE, carry text notifications from server to client over an HTTP connection. In the browser, EventSource provides the interface; the event stream uses text/event-stream. The connection is one-way. Commands from client to server need a separate route, such as ordinary HTTP requests.
A notification about a running report job
A fictional portal receives this event block:
id: evt-12
event: job-status
data: {"jobId":"J-52","status":"running"}
The blank line ends the block. Event identifier, event type and payload have different roles. Here the server reports that creation is running; the notification does not mean the file is ready. The field values are our own example.
After a recoverable interruption, EventSource can reconnect automatically. A previously set, non-empty event identifier is reported through Last-Event-ID. The server must decide whether and how it provides missing notifications again. The identifier does not create a stored event history.
The application therefore needs to handle duplicate notifications and history that is no longer available, for example by fetching the current job state again. SSE does not guarantee that a business action is performed exactly once. Access to the project and job must also be checked when connecting and when delivering notifications.
Sources
Related terms
- Message acknowledgementA message acknowledgement tells the broker that a delivery has been received or processed according to the agreed rule.
- Entity tagAn ETag identifies a particular representation version of an HTTP resource and supports conditional reads or changes.
- Cross-Origin Resource SharingCORS controls browser access to responses across origin boundaries. It replaces neither API login nor permission checks.
- Electronic Data InterchangeEDI transfers structured business documents between systems. Format, partner profile, data mapping and responses need to agree.
- Real-time processingReal-time processing handles arriving events against a defined latency target. Event time, processing time and late data need explicit rules.
- Batch processingBatch processing handles a defined set of data or jobs together in one run.
Articles on this topic
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.