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