users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Sun, 5 Feb 2017 17:19:52 +0000

Sorry, that was a wrong thread
On 05/02/17 17:17, Sergey Beryozkin wrote:
> 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:
>>>
>>> https://java.net/jira/browse/JAX_RS_SPEC-544 :-)
>>>
>>> -Markus
>>>
>>> *From:*Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
>>> *Sent:* Freitag, 3. Februar 2017 11:16
>>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>>> *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
>>>
>>
>