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 @WebSocket public java.util.Stream<ChatComment> getChatComments() {
return this.mySourceStream.filter(…).map(…);
}
This is aligned with Java EE 8's base platform which is Java SE 8, providing
java.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 @SSE much in the same
way as @GET implies @HttpMethod, opening a way to extend from WebSockets to
more SSE technologies (even @COMET or 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