users@tyrus.java.net

Re: WebSocket EndPoint Meta Information / WebSocket Supported MIME Types

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Fri, 04 Apr 2014 09:56:33 +0200

Hello Priya,

please see inline.

On 03/04/14 23:51, priyam80us_at_gmail.com wrote:
> Basically we are looking at coming up with a WebSocket Test Client to
> test
> a.)If the WebSocket EndPoint is active or not.
> b.) WS Endpoint is able to receive request and return response.
>
> For Test Client we would like to know how to determine the input
> request type to the WS Endpoint.

there is nothing like "request type" in websocket. It is very different
from SOAP/REST workflow. WebSocket protocol specifies handshake and
further communication.

Only handshake uses HTTP (request, response), further communication
specified in WebSocket RFC - https://tools.ietf.org/html/rfc6455.

ad a) that should be easy. You can just create connection and wait for
@OnOpen method invocation. Once it is done, you know that websocket
endpoint is alive.
ad b) this is more complicated and will always depend on the endpoint
implementation.

>
> Does WebSocket support only sending and receiving Text Messages ?

no, there is several types - text/binary/control. Control messages can
also carry some payload (ping and pong frames).

> Is there any way to determine the Metadata Information from WebSocket
> EndPoint.

Currently no. There is nothing like WADL or WSDL for websocket
application. We will need to find some other way how to expose these
information..

>
> Most of the samples are dealt with the text messages.
>
> So most of the client ui provides the user to enter an input which the
> Websocket client sends it across to the server and posts back the
> response it received from the server to the client. The mime types for
> most of the request and response is text. Is mime types supported by
> websocket restricted to TEXT ?

there is no mime type in WebSocket protocol. You can send only 3 types
of frames (as already mentioned, text/binary/control). You can face
other issues - you can send a message to a websocket endpoint and it
might not return any response, it depends on that endpoint
implementation. Also, received message can always change state of the
endpoint or application, there is nothing like HTTP GET.

Have you considered using javascript client for your usecase? If you are
thinking about implementing this as part of some webpage, then that may
be better way how to proceed.

Hope it helps, feel free to ask any followup questions!
Regards,
Pavel