3 ms·

Academic discussion: wouldn't the "stateless" part of REST preclude using a stream that necessarily needs to keep track of state? Practical discussion: the big

Academic discussion: wouldn't the "stateless" part of REST preclude using a stream that necessarily needs to keep track of state? Practical discussion: the biggest advantage of using REST is that you had a client readily available in pretty much every language. Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does.

zeveb 9y ago
> Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does. HTTP has supported streaming data for years, e.g. Server-Sent Events[0]. The short version is that you GET a URL, and the body keeps on arriving forever. I'm pretty sure that we had this sort of HTTP streaming back in the late 90s … I'll grant that many JSON-oriented pseudo-REST clients probably don't support it, though. [0] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events
- Thaxll 9y ago
  Server sent is not stream, it's a pseudo bad implementation on top of http 1.1.
  - jkarneges 9y ago
    How is SSE not a stream? HTTP 1.1 does a fine job of sending streaming content, and SSE is a stream-parsable content type.
- dguaraglia 9y ago
  Right, but server-sent events work only one way: from server to client. gRPC allows you to create bi-directional streams, where both the client and server are pumping data. Chunked encoding allows to do something like what gRPC does, but it's my understanding (I might be wrong) that the data needs to be base64 encoded, whereas HTTP/2 supports raw byte arrays to be sent.
  - jkarneges 9y ago
    HTTP/1 responses carry raw bytes, and chunked encoding doesn't affect that (just some packet length prefixing). If you mean binary data would need to be Base64-encoded with server-sent events, that's true. SSE uses text/event-stream as the content type, which is expected to be text. It would be interesting if someone defined a content type for streaming binary events.

zeveb 9y ago

> Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does. HTTP has supported streaming data for years, e.g. Server-Sent Events[0]. The short version is that you GET a URL, and the body keeps on arriving forever. I'm pretty sure that we had this sort of HTTP streaming back in the late 90s … I'll grant that many JSON-oriented pseudo-REST clients probably don't support it, though. [0] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events

Thaxll 9y ago
Server sent is not stream, it's a pseudo bad implementation on top of http 1.1.
- jkarneges 9y ago
  How is SSE not a stream? HTTP 1.1 does a fine job of sending streaming content, and SSE is a stream-parsable content type.
dguaraglia 9y ago
Right, but server-sent events work only one way: from server to client. gRPC allows you to create bi-directional streams, where both the client and server are pumping data. Chunked encoding allows to do something like what gRPC does, but it's my understanding (I might be wrong) that the data needs to be base64 encoded, whereas HTTP/2 supports raw byte arrays to be sent.
- jkarneges 9y ago
  HTTP/1 responses carry raw bytes, and chunked encoding doesn't affect that (just some packet length prefixing). If you mean binary data would need to be Base64-encoded with server-sent events, that's true. SSE uses text/event-stream as the content type, which is expected to be text. It would be interesting if someone defined a content type for streaming binary events.