On 16 May 2013, at 09:07, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> Hi (again) :)
Don't worry, I next have to do something boring with XSL, WADL and JQuery next. That should keep be of this list for a little bit. :-)
>
> reponse to OPTIONS is not defined; Tyrus does not handle it, so it passes back to container and if there is no other filter which would want to respond, 404 is returned.
>
> I don't see an issue (as Tyrus developer), but I agree there could be something useful returned (wsadl? :). I think we should NOT produce something standard, like list of allowed http methods, simply because there is another requirement - upgrade header have to be present. Do you have any suggestion about what we could return?
Hmm I hadn't actually thought beyond just a few HTTP headers, for example
OPTIONS /chat HTTP/1.1
.......
HTTP 1.1 200 OK
Allow : GET
Upgrade: websocket
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
I think it wold be safe to return the Upgrade header without a Connection header; but this might cause other problem. Also the use of the Sec- headers means that JavaScript clients in a browser wouldn't be able to access this functionality if I understand the restrictions properly.
But since you mention it I guess we could go with something very close to WADL since we already have Path parameters and query parameters to describe:
{
"resources" : {
"@base" : ".....",
"resource" : {
"@path" : "service",
"method" : {
"@name" : "GET",
"@upgrade" : "websocket; subprotocol=chat; version=13+",
"request" : {
"representation" : { "@mediaType" : "application/json; charset=UTF-8", "@describedBy" : "message" }
"representation" : { "@mediaType" : "application/json; charset=UTF-8", "@describedBy" : "groupAction" }
"representation" : { "@mediaType" : "application/json; charset=UTF-8", "@describedBy" : "pounceAction" }
}
"response" : {
"representation" : { "@mediaType" : "application/json; charset=UTF-8", "@describedBy" : "message" }
}
}
}
}
}
(Yeah I know there is no mime type in websocket; but it does give us something to describe the data)
We are getting very close to replicating Swagger Socket; but perhaps that is the reality for most Web Socket applications? What is your feel do most WebSocket applications just pass the same type of message back and forth or do they generally have a more complicated vocabulary.
> I was thinking about something 'like' wadl, but don't want to create "just another proprietary descriptor". Another solution might be having standard rest resource somewhere and feed it with data from Tyrus..
>
> Another problem might be with definition of what should be shared - list of URIs/path templates? We could add some info about message handlers, but only for annotated endpoints, since programmatic ones are created when onOpen is called..
Yeah it would have to gracefully degrade, showing only templates and parameters at the start and displaying schema representations should the data get more interesting. (At minimum it could say String -> text/plain; charset=UTF-8 and byte[]->application/octet-stream) I wonder if the Encoder and Decoders could be decorated in such a way to expose what objects are acceptable. This would make it easy to populate the request/response blocks in the Endpoint case from the list of coders that would be registered at run time.
But whether there would be a use for this is another mater.... certainly it would make it easier for Java and HTML5 tooling to provide help for the user. We are not sure yet just how much help they might need.
Cheers,
Gerard
>
> Pavel
>
> On 5/15/13 2:53 PM, Gerard Davison wrote:
>> Hi,
>>
>> So I was playing about with a simple Web Socket endpoint deployed to a a local Grizzyly container using the following code:
>>
>> Server server = new Server("localhost", 8025, "/", EchoBean.class);
>> server.start();
>>
>> As an experiment I tried to do an OPTIONS request on the http://localhost:8025/echo but I got 404 returned, I am not sure what I was expecting but not that.
>>
>> What would be a reasonable response? The reason I am asking is that it would be really nice if client tooling could ask a question and be able to identify a Web Socket resource without trying to connect. I am not aware of a header pair such as TE/transfer-encoding for Upgrade perhaps I am just missing it in the RFC.
>>
>> Thanks,
>>
>> Gerard
>>
>