>>>> * 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?
> I'm not sure I understand the JAX-RS Client API part. Is the JAX-RS
application a WS client in this UC? If so, it can simply use a WS
@ClientEndpoint.
The scenario is a JAX-RS service which also supports WebSocket. "Normal"
REST clients use "GET" polling, "modern" clients might want to upgrade to
WebSocket:
1. Client-App uses JAX-RS Client API to send "GET" with "Upgrade: websocket"
(etc.) to JAX-RS server.
2. JAX-RS server responds with "101 Switching Protocols" and hands over the
tcp connection to WebSocket API server endpoint.
3. JAX-RS server posts events asynchronously to Client-App via the WebSocket
connection.
Hence, Client-App is both, JAX-RS Client initially, but WebSocket Client
after that. And server is JAX-RS server initially, but WebSocket server
later. The question is, how to code the hand-over of the tcp connection on
both ends? The optimal solution would be that JAX-RS API supports that, so
that a JAX-RS server application can answer the intial "GET" with "return
myWebSocketEndpoint" and the JAX-RS client application will receive a
WebSocket client endpoint in turn. :-)
>> If we allow SSE, then people will ask how to do something like that with
WebSocket and need a one-stop blueprint shop.
> We can certainly say something about WS, and why SSE is easily handled as
an extension of JAX-RS while WS requires its own API.
I think that would be beneficial, as from the bird's view, both are
HTTP-initiated push services, so question will will arise how to use it
together with JAX-Rs and why not supporting it etc.