Feature Request: Server streams for general REST APIs

[devnev]

I've tried using vanguard-go as it seemed appealing to get all of REST, connect and grpc in one go. However, when I got to a streaming API the REST variant gave an error indicating that it is unsupported. It looks like from the implementation that only HttpBody responses can be streamed. So in the end I've gone back to connectrpc+(grpcgateway+grpchan) which has reminded me while vanguard-go seemed so appealing in the first place 😁 ...

Are there any plans for supporting arbitrary response stream types?

I understand there's a bunch of concerns, in particular how to send the final status - e.g. trailers are still very, very far from being supported by browsers to a degree that would make them suitable for the response status. Content-type negotation might be a passable way to get around these, i.e. the client has to opt in to a certain way of streaming responses by having a particular protocol version in its accept header.

[emcfarlane]

Hi devnev, theres not currently a well defined spec for how streaming RPCs map to REST style requests. There is support for file streaming with the use of google.api.HttpBody. Streaming implementation usually want to use something like websockets or the new WebTransport (HTTP3) but this is very project specific. So to support streaming I think we'd want to provide pluggable protocols to allow users to change the client encoder to fit their use case. However, there is no planned support for this.