Support for server sent events

[abhishekjamloki]

Hello, I am trying to consume the following using retrofit

https://mesosphere.github.io/marathon/docs/rest-api.html#get-v2-events I could not find a suitable command/documentation for consuming server sent events. Does retrofit currently support it ? If not is it on the roadmap for future releases.

Thansk!

[caseykulm]

http://square.github.io/retrofit/javadoc/retrofit/http/Streaming.html

Also https://github.com/square/retrofit/issues/568

Also https://github.com/square/retrofit/releases/tag/parent-1.6.0

So basically annotate your @GET("/v2/events") with @Streaming as well.

[JakeWharton]

We don't offer a way to handle this automatically including deserialization of these events (usually people wanting this use websockets which we do plan to support). That said, I'm pretty sure there's a way to hack a CallAdapter and Converter pair together to make this work. I'll have to give it a go some day this week and see what I can come up with.

[JakeWharton]

Spec https://html.spec.whatwg.org/multipage/comms.html

Info:

• http://www.html5rocks.com/en/tutorials/eventsource/basics/
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
• http://caniuse.com/#feat=eventsource

An interesting spec. The "data:" prefix seems wasteful, but hopefully no one has a newline-laden message body. I would have preferred a series of length-prefixed, opaque binary payloads for the message bodies.

[JakeWharton]

Been thinking about this for a while, and I have an idea of the approach I want to take when I get around to implementing. Merely writing it down so I don't forget when I come back to this post-beta2.

The semantics of Call prevent reusing its type for this, and that's probably a good thing since it fundamentally (sort of) differs from a one-shot request/response exchange. Another type will be introduced (likely in a sibling artifact) for representing SSE calls. For the purposes of discussing it, we'll name it EventCall.

There will be an EventCallAdapterFactory which needs registered with Retrofit.Builder. It will match the EventCall return type on service methods. It will require the @Streaming annotation be present on the method. Unlike a normal CallAdapter.Factory, it will cache the response type in its created CallAdapter, but return ResponseBody from responseType(). This, combined with the required @Streaming annotation will allow the CallAdapter instance effective access to the streaming socket.

EventCall will be parameterized just like Call and as previously mentioned that response type will be cache, but not exposed. A Converter will be obtained from the Retrofit instance for the response type which will be used for deserializing each server-sent message. It is the responsibility of this converter to deal with variance in the message types. That is, only one type will be exposed and if the user wants different message types then a common superclass of interface must be used and some other means of casting in user-code to the right type.

When a ResponseBody is received its source() will be wrapped in a custom Source that exposes the individual messages as single Source instances that can be wrapped up in their own ResponseBody instances, passed to the Converter, and the resulting object fed back to the user. This is will be similar to how websockets work in OkHttp.

EventCall will expose an asynchronous method. It takes a callback, very similar to Call, except that the successful callback will be called once for each event. It's not clear whether synchronous is useful here as it undermines the transport mechanism (by providing something like an Iterator<T>), but perhaps there's room for synchronous connection and then attaching the callback?

RxJava integration lends itself well to this model, but having this ship as a separate artifact creates an unfortunate wannabe-love-triangle of dependencies that prevent the simple integration. Since we have no way of differentiating Observable<T> for normal request/response and Observable<T> for SSE we'll probably need a method-level annotation to denote, which will lend itself to the separate artifact anyway, but resulting in the need for this CallAdapter.Factory to be registered before the normal RxJava one. But this can be figured out after all the aforementioned things are integrated.

[kgpmurray]

Is this still in the pipeline? If so do you have a rough timetable for release?

[JakeWharton]

No timeline. Unsure if we'll ever support it natively.

On Wed, Aug 17, 2016 at 12:03 PM Keith Murray notifications@github.com wrote:

Is this still in the pipeline? If so do you have a rough timetable for release?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/square/retrofit/issues/1029#issuecomment-240460365, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEcQWhLkyqXqKzZw2LZnkLB53nhEkks5qgzDRgaJpZM4FxUsd .

[RyanRamchandar]

There is one other Android library which handles Server-Sent Events found here: https://github.com/tylerjroach/eventsource-android

Having this integrated in Retrofit2 would be convenient.

[marcelpinto]

@RyanRamchandar we did an implementation, is still under development and we need to change few things, but you can use it as a reference. https://github.com/heremaps/okhttp/tree/master/okhttp-sse

[jcloquell]

As the 2.2.0 version was released a couple of months ago and this was not included, are there any plans to support SSE with Retrofit any time soon? And by the way @skimarxall the link https://github.com/heremaps/okhttp/tree/master/okhttp-sse is not working anymore, is there any place where I can find the implementation even if it's still under development?

[marcelpinto]

We adopt a different approach, instead of trying to add it in the OkHttp lib, we re-build it as a plugin. The library is under legal review since we are releasing it under my company GitHub, this process is slow sometimes but I expect to have it live soon. I will then update the link.

Btw we are using OkHttp not retrofit.

[Petrulak]

@skimarxall please keep us updated once You make the library public.

[jaroslawk]

@skimarxall is there any update on SSE? we are just looking for something like that for our service.

[marcelpinto]

I'm sorry for the delay but for internal reasons the open source review has been delayed. I'll try to push it so in the upcoming weeks it's released.

On Fri, Jun 23, 2017, 15:23 jaroslawk notifications@github.com wrote:

@skimarxall https://github.com/skimarxall is there any update on SSE? we are just looking for something like that for our service.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/square/retrofit/issues/1029#issuecomment-310664097, or mute the thread https://github.com/notifications/unsubscribe-auth/AChIaUwGQ7j1aOXhnFBkgVxq-KfV_hiUks5sG7xogaJpZM4FxUsd .

[jaroslawk]

Thank you! 👍

[marcelpinto]

Finally, we publish our SSE library (OkSse) https://github.com/heremaps/oksse

[milenpav]

Some changes here @JakeWharton

[chuxubank]

Since OkHttp already supports SSE I'm looking forward to seeing SSE support on Retrofit also 😃 .