Re: [Resteasy-developers] New HornetQ REST Interface

[Jeff M. <jm...@re...>]

Le 10 août 2010 à 16:44, Bill Burke a écrit :

> Jeff Mesnil wrote:
>> Hi Bill,
>> To get familiar with the REST interface, I am writing a demo which showcases how HornetQ can be used on the Web using either REST or HTML5 WebSockets (depending on the env).
>> From mobile browsers, I am using the REST API to send a JSON string that goes through a JMS Topic.
>> One of the subscriber on that topic is using HTML5 WebSockets to receive from the topic and the message body MUST be a String (WebSockets implementation does not allow binary content).
>> My app setup is a bit convoluted but the idea is that I know I am dealing with text and I want to deal with text throughout all the layers.
> 
> I thought WebSockets existed so that you could create a raw socket connection between the browser and server?  So that you wouldn't have to tunnel custom protocols through HTTP.  I don't understand why you want to use the REST API through WebSockets.  The REST API leverages the HTTP application protocol, it doesn't fight it.

Ok, my explanation was not clear.
One part of the demo use the REST API to publish messages from mobile browsers.
Another part of the demo (a monitor application) uses WebSockets to receive messages.

I don't want to use the REST API over WebSockets, I agree that makes no sense.
But HornetQ has support for Stomp over WebSockets[1]. WebSockets are like TCP sockets and the Stomp layer above it adds messaging semantic.
The issue I am facing is that current WebSocket implementations (at least in WebKit) supports only text data and not binary data. 
This implies that the message coming from HornetQ MUST be a Text message and not an Object or Bytes message.

I think that in most cases, people will use the REST API to send text (XML, JSON, etc.) and I'd like a way to declare the message with a TEXT body when it enters HornetQ so that all other parts will treat it as is (JMS consumers, WebSocket clients, etc.)

> Personally, I don't want REST clients to know or care that they are interacting with a JMS-based system.

I understand that. That's why I proposed a X-HornetQ-Type (as opposed to X-Messaging-Type) header to make it clear it is an added value of HornetQ integration when you *know* how you interact with the system.
In ConsumedMessage, you distinguish between a HTTP message and an ObjectMessage. I think that the Text case is important enough to be taken into consideration too.

> Not interested at the moment in your patch because I don't see the value-add.  Have you seen the jms-to-rest demo and this documentation?
> 
>> http://docs.jboss.org/resteasy/hornetq-rest/1.0-beta-1/userguide/html/ch09.html

Yes I read it. However in my case, I don't have that control: The message is translated from HornetQ Core to a Stomp frame with binary data while I need to have it as text data to receive it through WebSockets.

>> I was thinking about adding a custom HTTP header (e.g. X-HornetQ-Type: text) so that I can chose how to store the message body in PostMessage.publish() either as a byte[] or as a String. This way the message will enter HornetQ with as a text message and the other layers will treat it accordingly (including potiental JMS consumers)
>> I don't want to use Content-Type to decide of the message's body type (I have no idea which Content-Type would correspond to text and I don't want to maintain a white list).
> 
> Sure you know a content-type corresponds to text or not
> 
> text/*
> application/*+json
> application/*+xml
> application/*+yaml

and 
multipart/mixed
message/rfc822 (whatever that is)

What about user-defined MIME types?

Would you consider a patch to convert the message to a Text message according to a list of content-type?

jeff

[1] http://jmesnil.net/stomp-websocket/doc/

--
Jeff Mesnil <jm...@re...>
Core Developer (HornetQ)
JBoss by Red Hat