users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Sun, 14 Dec 2014 20:34:52 +0000

Hi Marek,
I've no problems with 2.1 not pursuing it further. Indeed, as Markus
suggested, it was not about introducing a new API, but about a binding
to a WS transport in a seamless/opaque way. But I can imagine some
people being concerned about it due to WebSockets not being done over
HTTP alone. SSE is not RESTful either but it is over-HTTP style does win
as far as its linking to JAX-RS at a standard level is concerned
Sergey
On 11/12/14 16:59, Marek Potociar wrote:
>
>> On 11 Dec 2014, at 17:55, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>>
>> On 11/12/14 16:43, Marek Potociar wrote:
>>>
>>>> On 10 Dec 2014, at 23:54, Markus KARG <markus_at_headcrashing.eu
>>>> <mailto:markus_at_headcrashing.eu>> wrote:
>>>>
>>>>>> * The list names SSE but not WebSockets. Is this to be understood as
>>>> really
>>>>>> SSE only, hence definitively no WebSocket support?
>>>>> There's another JSR for WS.
>>>>
>>>> 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.
>>>
>> People do use it though for doing interactive Web UI applications. I
>> don't have the statistics of how widely it is used but it is probably
>> more deployed than SSE, at this moment of time.
>> It might be reasonable to do some work, may be in the future, to let
>> JAX-RS developers to participate in such activities too,
>>
>> Opening an ice-box JIRA is a good compromise IMHO :-), no specific
>> targets but can be tracked
>
> Frankly, I do not see us introducing another WebSocket API in Java EE.
> We would need to present a lot stronger arguments to Java EE platform
> spec leads rather than “JAX-RS users use WebSocket a lot in their
> applications”. Let’s focus on areas where we can be realistically
> successful instead.
>
> Cheers,
> Marek
>
>>
>> Thanks, Sergey
>>
>>> Cheers,
>>> Marek
>>>
>>>>
>>>>>> If that is true, then it
>>>>>> might at least good to add an example to the specification how to use
>>>>>> WebSockets with JAX-RS and describe why there is no need for explicit
>>>>>> WebSocket support due to that.
>>>>> I don't know if this belongs in our spec, but maybe a best practice
>>>>> document or something like that. Are you volunteering? ;-)
>>>>
>>>> As long as you tell me how JAX-RS and Java WebSocket API can be used
>>>> together I'll provide the code sample and some explanative lines if you
>>>> like. I have no clue about the Java WebSockets API as I always
>>>> thought it
>>>> shouldn't be an standalone API but has to be part of JAX-RS... ;-)
>>>>
>>>>>> * Why is it JSR 370's responsibility to evaluate MVC requirements
>>>>>> when there
>>>>>> is a separate MVC JSR? What is expected from the JSR 370 EG which
>>>>>> cannot be
>>>>>> done by the MVC EG?
>>>>> _If_ MVC decides to build on top of JAX-RS (TBD), then we _may_
>>>>> need to evaluate requirements coming from them.
>>>>
>>>> Understood. So it's their turn initially.
>>>>
>>>> Regards
>>>> -Markus
>>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog:http://sberyozkin.blogspot.com <http://sberyozkin.blogspot.com/>
>