Markus, All,
I've opened a 2.1 enhancement request:
https://java.net/jira/browse/JAX_RS_SPEC-449
I think it would be great to have a typed variant even without SSE
Thanks, Sergey
On 10/03/14 21:06, Sergey Beryozkin wrote:
> On 10/03/14 20:42, Markus KARG wrote:
>> I think adding support for SSE to JAX-RS would allow to standardize an
>> API for a common type of application development problem: How to keep
>> the client updated to server side changes?
>>
>> Example: Chat system.
>>
>> Common solution in JAX-RS 2.0: Any type of periodic GET (a.k.a polling
>> et al), like
>>
>> @GET public java.util.List<CharComment> getChatComments() {
>>
>> return /* …all_chat_comments… */;
>>
>> }
>>
>> Possible solution with SSE: Get content of thread so far using initial
>> GET, then wait for more thread postings using SSE (inversion of control
>> regarding poll-vs-push).
>>
>> But clearly, I do not like the way Jersey proposes it. The API looks not
>> very RESTful, it more looks like "Servlet++".
>>
>> Instead, if we decide to support SSE, we should concentrate on REST and
>> only add that parts of API that still are RESTful and fit nicely into
>> JAX-RS as it is designed currently.
>>
>> My proposal would be that the API should look like this:
>>
>> @GET *_at_WebSocket* public *java.util.Stream<*ChatComment*>*
>> getChatComments() {
>>
>> return this.mySourceStream.filter(…).map(…);
>>
>> }
>
> I think I really like it:
> - use a dedicated annotation, the enabler, instead of overloading Produces
> - Typed stream support; I was thinking yesterday more about introdocing
> a typed StreamOutput variant. Jersey uses EventOutputStream clearly
> usable in scope of SSE only, something like what Markus suggests, that
> can be used with and without SSE, with different data types, will do well
>
> Sergey
>
>>
>> This is aligned with Java EE 8's base platform which is Java SE 8,
>> providingjava.util.Stream<T>as an endless pipeline of <T>events send by
>> server. I assume anybody aware of the new Stream API will recognize what
>> a method with such a signature will do: Provide not only a single
>> ChatComment, but actually an endless stream. It is just a simple
>> extension to what a GET does, actually only shifting the time when that
>> GET ends -- defined by the client application. The @WebSocket annotation
>> implies @SSEmuch in the same way as @GETimplies @HttpMethod, opening a
>> way to extend from WebSockets to more SSE technologies (even @COMETor
>> other legacy solutions). If JAX-RS provides support for SSE, then
>> WebSockets is a MUST, since it seems to be the most "native" SSE
>> extension to HTTP GET. My proposal obviously implies that there is some
>> source stream injected which serves as the origin of the SSE events, and
>> that the JAX-RS engine is utilizing ManagedExecutorServer (Java EE) or
>> some unmanaged ExecutorService (Java SE). As an alternative, in Java EE
>> environments, the source can be attached to CDI events, hence CDI's
>> event dispatcher drives this chain.
>>
>> As you see, my proposal is much less defined around technical
>> implementation, but much more around developer's readability and
>> simplicity of the API. Also it is at-most aligned to Java 8. But
>> certainly, it does not open doors for any fancy thing one could imagine
>> with SSE channels in mind, but solely is defined to solve one clear
>> RESTful problem: How to keep the client updated after an initial GET.
>> And I think, that is the sole SSE item which has to be covered in a
>> future RESTful API. Everything else, in my understanding, is not
>> RESTful, hence is not necessarily to be covered by JAX-RS.
>>
>> Regards
>>
>> Markus
>>
>> *From:*Marek Potociar [mailto:marek.potociar_at_oracle.com]
>> *Sent:* Mittwoch, 5. März 2014 16:39
>> *To:* jsr339-experts_at_jax-rs-spec.java.net
>> *Subject:* [jsr339-experts] Adding SSE support to JAX-RS 2.1?
>>
>> Hello experts,
>>
>> As you may know, the first steps towards starting work on Java EE 8 has
>> been made already. Among the most important ones was the Java EE 8
>> Community Survey. As the survey results
>> <https://java.net/downloads/javaee-spec/JavaEE8_Community_Survey_Results.pdf>
>> indicate,
>> there is a very strong support in Java EE community for coming with a
>> standard API for supporting Server-Sent Events in Java EE 8. Clearly,
>> one way or the other, SSE support will be added in Java EE 8 platform.
>>
>> There are multiple options how to achieve this and one of these options
>> being considered is to extend JAX-RS API to provide better support for
>> SSE. Before we make a final decision, I'd like to get your feedback on
>> whether or not you think that extending JAX-RS API with SSE support is a
>> good idea.
>>
>> To get the idea how such JAX-RS API support could look like, please
>> check Jersey User Guide section that describes how client and server SSE
>> support is currently implemented in Jersey 2.x:
>>
>> https://jersey.java.net/documentation/latest/sse.html#overview
>>
>> I am looking forward to your feedback.
>>
>> Thank you,
>>
>> Marek
>>
>