3 ms·

Also streaming that you can't do with regular REST, so think about push notification and the like. One of the biggest advantage imo is the contract between the

by Thaxll 9y ago

Also streaming that you can't do with regular REST, so think about push notification and the like. One of the biggest advantage imo is the contract between the client and the server, both are always in sync about what to send / receive. I've seen many times things break because x,y,x added a field or change a type that the server / client couldn't understand.

dragonwriter 9y ago
> Also streaming that you can't do with regular REST Nothing about the REST architectural style prohibits a resource (or, rather, a particular resource representation) from being a stream.
- Thaxll 9y ago
  What protocol / library do you use for that? afaik there is nothing since this can only works properly on HTTP/2 which REST doesn't really use.
- dguaraglia 9y ago
  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.
- Xorlev 9y ago
  HTTP/1.x will allow you to stream requests from the client. It'll also let you stream chunked responses from the server. But it won't let you do both simultaneously without going more exotic. Speaking from my own experience in Java, especially testing my gRPC/HTTP bridge[1], streaming is never overly easy with HTTP clients. You're usually just handed a byte stream to handle yourself. Streaming to the server from the client has been another really interesting exercise to get right. That's part of what's nice about gRPC (aside from the RPC model and protobuf serialization). If you want unary semantics, done. If you want streaming, it's just a keyword away, and it works across all languages. [1] https://github.com/Xorlev/grpc-jersey https://github.com/Xorlev/grpc-jersey
  - chrissnell 9y ago
    Can't speak for Java but it was super easy in Go. I wrote some software for my home weather station and it streams [1] over gRPC to another little Go app [2] that runs on my laptop, wherever it may be. My use is not at all complex but I can't imagine that more involved streaming would be any tougher. [1] https://github.com/chrissnell/gopherwx/blob/master/storage_grpc.go https://github.com/chrissnell/gopherwx/blob/master/storage_g... [2] https://github.com/chrissnell/grpc-weather-bar https://github.com/chrissnell/grpc-weather-bar Edit: here's a simple example protobuf definition for streaming to a client: https://github.com/chrissnell/gopherwx/blob/master/protobuf/grpcweather.proto https://github.com/chrissnell/gopherwx/blob/master/protobuf/...

by Thaxll 9y ago

dragonwriter 9y ago

> Also streaming that you can't do with regular REST Nothing about the REST architectural style prohibits a resource (or, rather, a particular resource representation) from being a stream.

Thaxll 9y ago
What protocol / library do you use for that? afaik there is nothing since this can only works properly on HTTP/2 which REST doesn't really use.
dguaraglia 9y ago
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.
Xorlev 9y ago
HTTP/1.x will allow you to stream requests from the client. It'll also let you stream chunked responses from the server. But it won't let you do both simultaneously without going more exotic. Speaking from my own experience in Java, especially testing my gRPC/HTTP bridge[1], streaming is never overly easy with HTTP clients. You're usually just handed a byte stream to handle yourself. Streaming to the server from the client has been another really interesting exercise to get right. That's part of what's nice about gRPC (aside from the RPC model and protobuf serialization). If you want unary semantics, done. If you want streaming, it's just a keyword away, and it works across all languages. [1] https://github.com/Xorlev/grpc-jersey https://github.com/Xorlev/grpc-jersey
- chrissnell 9y ago
  Can't speak for Java but it was super easy in Go. I wrote some software for my home weather station and it streams [1] over gRPC to another little Go app [2] that runs on my laptop, wherever it may be. My use is not at all complex but I can't imagine that more involved streaming would be any tougher. [1] https://github.com/chrissnell/gopherwx/blob/master/storage_grpc.go https://github.com/chrissnell/gopherwx/blob/master/storage_g... [2] https://github.com/chrissnell/grpc-weather-bar https://github.com/chrissnell/grpc-weather-bar Edit: here's a simple example protobuf definition for streaming to a client: https://github.com/chrissnell/gopherwx/blob/master/protobuf/grpcweather.proto https://github.com/chrissnell/gopherwx/blob/master/protobuf/...