[jax-rs-spec users] Re: High Level API for SSE support

From: Sergey Beryozkin <>
Date: Sun, 5 Feb 2017 17:17:38 +0000

Hi Pavel
There was an issue I was trying to raise when the SSE draft was
originally proposed.
Specifically, it was about a default media type for SSE data.
Right now one needs to set a media type with the SSE builder. The
question was if we could let people use @Produces,
so that they do not set it every time an SSE data is returned, similarly
to the way it is done in the 'traditional' JAX-RS - one either
uses @Produces or uses Response to customize

What do you think ?

Thanks, Sergey
On 03/02/17 17:56, Pavel Bucek wrote:
> perfect, thanks! :-)
> On 03/02/2017 18:50, Markus KARG wrote:
>> :-)
>> -Markus
>> *From:*Pavel Bucek []
>> *Sent:* Freitag, 3. Februar 2017 11:16
>> *To:*
>> *Subject:* Re: High Level API for SSE support
>> Hi Marcus, Sergey,
>> thanks for thinking about this topic and coming with an enhancement
>> (or maybe extension is a better name).
>> I believe the idea is a sound one. I also share Sergeys opinion that
>> JAX-RS should provide SSE support on the level which is currently
>> proposed.
>> I know you won't like this, but.. can you please formalize your
>> proposal as a jira ticket?
>> We need to keep "closing" stuff instead of adding and I we don't even
>> have any comprehensive review of the proposed SSE yet. If we'd
>> include this as part of it, it would most likely significantly
>> prolong the review period, not mentioning that it can be treated as
>> completely separate feature. We can call it "High level SSE API".
>> Also, the idea will need some work - currently, there is no mention
>> of the message format (I believe it will need to be pluggable, we
>> don't want to define any "standard" there), relation to the existing
>> API (esp. broadcaster), etc.
>> Having said that, please don't take it as "I don't want to hear your
>> thoughts" - it's exactly the opposite. But I believe there is a
>> general conclusion: "we want to have API similar to what has been
>> proposed by JAX-RS Spec leads". Let's finish that one. We can build
>> on top of it later.
>> Thanks and regards,
>> Pavel
>> On 03/02/2017 10:41, Sergey Beryozkin wrote:
>> I think the proposed SSE API should stay (to let users control
>> SSE flows in a fine grained manner when needed),
>> However offering the users an option to cover the basic SSE flows
>> with the use of annotations is interesting which
>> if accepted should be complementary IMHO
>> Cheers, Sergey
>> On 02/02/17 23:22, Markus KARG wrote:
>> Experts,
>> Oracle's current SSE API proposal clearly is a good API for
>> SSE. The question is, whether it really fulfils what
>> application developers expert from JAX-RS in particular.
>> There might be programmers that don't like to explicitly
>> learn a new (and rather complex) set of classes and methods
>> just to get the additional benefit of update notifications,
>> and that the style of the SSE API does not very well fit into
>> the style of JAX-RS. SSE API is completely algorithmic, while
>> server-side JAX-RS is mostly declarative. I could imagine
>> that some programmers would love to get a high-level SSE
>> support in JAX-RS that more looks like "SSE inside JAX-RS"
>> and less like a standalone SSE API.
>> To illustrate, let me give an example. Think of a simple CRUD
>> application that works pretty well in JAX-RS 2.0 already
>> (@POST / @GET / @PUT / @DELETE). Now the developers decide
>> that once data is updated (PUT) or deleted (DELETE), the
>> client shall be notified about that immediately using SSE
>> technology with minimal additional code. But the amount of
>> additional code lines with the new SSE API is really heavy
>> and clutters the previously clean application with lots of
>> SSE special code.
>> So I wonder whether it might be beneficial to provide some
>> high-level API that simplifies this use case?
>> For example, it could look like this (simplified for
>> illustration purposes):
>> @SSE public class MyResource {
>> @GET @SseInit public void notifications() {};
>> @POST public void create() {};
>> @GET @Path("{id}") public MyObject read() {};
>> @PUT @SseNotify public void update() {};
>> @DELETE @SseNotify public void delete() {};
>> }
>> The idea would be the SSE API as outlined by Oracle is used
>> under the hood by the JAX-RS container. Once a requests to
>> get SSE notifications by calling the @SseInit-annotated
>> GETter, the JAX-RS container sets up an implied SSE
>> subscription for that client with this resource. Whenever the
>> JAX-RS container leaves the body of @SseNotify-annotated
>> methods, it pushes notifications to that subscriptions (the
>> messages as synthetically built from the HTTP method and the
>> URL, so the client knows what the message means).
>> This is not as far as flexible as Oracle's full-blown SSE
>> API, but it is only intended as sugar ontop for simple but
>> frequent use cases.
>> -Markus