users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Welcome to the JAX-RS 2.1 EG

From: Markus KARG <markus_at_headcrashing.eu>
Date: Thu, 11 Dec 2014 19:34:46 +0100

>> What if somebody wants to write a JAX-RS application which shall open
>> a WebSocket as a reaction to an HTTP method, and which has to forward
>> events on that WebSocket received by JAX-RS Client API? If we allow
>> SSE, then people will ask how to do something like that with WebSocket
>> and need a one-stop blueprint shop. I doubt people would understand
>> that JAX-RS spec explains how to do such a scenario with SSE, but says
>> nothing about WebSocket, while WebSocket spec says nothing about
>> JAX-RS in turn. That's why I'm asking.
>To those people, my answer would be that SSE is a special case of media type working on top of HTTP request-response model. There is no further magic behind it and as such it can fit quite neatly into JAX-RS programming model. In WebSocket, there is no HTTP and no request/response relationship, which is why Java EE provides a separate API for WebSocket. Personally I’m not convinced that we need to bring WebSocket into the picture at all. SSE may look similar to WebSocket at first glance, but it is quite different really. IMO, WebSocket do not belong to JAX-RS spec, neither as a topic and nor as an example.

Looking at JAX-RS less protocol-bound but from a more abstract view, it already provides a clean separation of concerns: Pure Java domain model at left hand, and providers doing the "magic plumbing" at right hand. Now we bring the abstract idea of "Server Push" into that picture. If the JAX-RS still supports the clean separation of concerns, then your argument looks weak, because it is a purely technical (hence: right hand) argument. If we look at the application level (hence: left hand) there is no need to make any distinction between SSE and WebSockets. For the left hand, both provide technical ways to push, and both can be initiated by a simple "GET". What happens "under the hood" in fact _is_ magical plumbing. As soon as you deal with protocols directly, you remove the separation of concerns and force application level programmer to deal with implementation details. Is that really wanted?