Should streaming endpoints produce text/event-stream content?

[tmc]

https://html.spec.whatwg.org/multipage/comms.html#server-sent-events

This would allow newer browsers to use the EventSource APIs cleanly.

[yugui]

Interesting.
But at this moment, compatibility to Swagger is more important for us. Let me check the compatibility before decision.

[mwitkow]

We're also very much interested in this. The biggest benefit of using event-stream is that parsing a stream of JS events in a browser doesn't buffer up the whole content of the stream.

I think implementing this could be relatively easy. Adding special case of Accept: text/event-stream into the generated code that will return a single EventSource event called data with the proto JSON as payload, followed by an empty data to force an event trigger.

We're actually interested in doing this ourselves. @yugui, would you accept PRs for this?

[yugui]

We're actually interested in doing this ourselves. @yugui, would you accept PRs for this?

Yes, I will.

[tmc]

@mwitkow any action on this?

[tmc]

@yugui for swagger-compat questions: OAI/OpenAPI-Specification#396

[yugui]

I have read the spec of the server-sent events.
IIUC, the spec defines something different from the current line-based streaming. So I decided not to simply replace the current way of streaming with server-sent events.

But it might be useful if we can support server-sent events as a part of pluggable marshaling mechanism.

[hajsf]

But it might be useful if we can support server-sent events

Any update on this?

[johanbrandhorst]

No update yet, haha. This issue is 7 years old 😓. Lets try to see what we can do in the other issue first?