Major: Server-sent events (SSE)

[mkovatsc]

Server-sent events (SSE) are seriously bizarre; I think this could be
mentioned here.

We need some consensus on the "bizarreness" or at least to understand the expected guidance.

SSE work a bit like HTTP headers with an identifier event: followed by a user-defined string and newline (\n) and then the identifier 'data:' followed by a user-defined string without newline (can be a JSON structure) and terminated with an empty line (\n\n) -- bizarrely not using \r\n like HTTP headers...

I don't think we need to explain this in this document.

[cabo]

I don't think we need to explain this in this document.

No. I think the important observation is that SSE cannot do REST, as there is no transfer of representations, just header-like data.

[akeranen]

SSE is currently mentioned only as a workaround and text notes that it "reduces HTTP to a pure transport":

In HTTP, there exist a number of workarounds to enable server push, e.g., long polling and streaming [RFC6202] or server-sent events [W3C.REC-html5-20141028]. In IoT systems, long polling can introduce a considerable overhead, as the request has to be repeated for each notification. Streaming and server-sent events (the latter is actually an evolution of the former) are more efficient, as only one request is sent. However, there is only one response header and subsequent notifications can only have content. Individual status and metadata needs to be included in the content message. This reduces HTTP again to a pure transport, as its status signaling and metadata capabilities cannot be used.