jsr370-experts@jax-rs-spec.java.net

Re: High Level API for SSE support

From: Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com>
Date: Fri, 3 Feb 2017 09:30:54 -0500

> On Feb 3, 2017, at 4:41 AM, Sergey Beryozkin <sberyozkin_at_talend.com> 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

 I agree with Sergey. You cannot offer a high-level API before a low-level one, it’s just backwards. The notion of a high-level, declarative API goes beyond SSE and was already brought by others (at least by Bill B. once) for JAX-RS.

 We should focus on building a solid foundation first. Please take a look at the latest proposal, which I think is a nice improvement over the previous one.

— Santiago

>
> 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
>
>