- View SourceReading the docs at http://activemq.apache.org/ I noticed they have a
REST API. So I clicked on http://activemq.apache.org/rest.html to
read more and, perhaps not surprisingly, found that it's pretty broken
Adding a message to the queue seems fine... they give as an example
a queue at http://www.acme.com/queue/orders/input and you can add a
new message in the queue by POSTing to that URL. Fine.
Consuming a message from the queue, though, seems problematic.
They allow either GET or DELETE on the *same* URL to pop a message
from the queue.
They are aware that this is wrong:
"Note that strict REST requires that GET be a read only operation; so
strictly speaking we should not use GET to allow folks to consume
messages. Though we allow this as it simplifies HTTP/DHTML/Ajax
... but they don't seem to understand *how* wrong it is:
* it's not REST that says GET is a read-only operation; it's HTTP. So
their HTTP implementation is broken. Sadly seems to be pretty common.
* DELETE on a URL representing a queue means you want to delete the
entire queue, not a single message!
The reason I'm writing to this list is that I thought it was an
interesting case and I couldn't immediately think of better solution.
Has anybody thought of a good way to model a queue?
You could of course do a GET on the queue, returning a list of
available messages, then DELETE one of those - but that leads to
- View SourcePaul Winkler wrote:
>IBM just published their similar HTTP interface to WebSphere MQ.
> Reading the docs at http://activemq.apache.org/
> <http://activemq.apache.org/> I noticed they have a
> REST API. So I clicked on http://activemq.apache.org/rest.html
> <http://activemq.apache.org/rest.html> to
> read more and, perhaps not surprisingly, found that it's pretty broken
See the PDF, especially chapter 5 and 8 for the details regarding their
use of HTTP. Now, they don't claim to be RESTful, but they do seem to
care about being good HTTP citizens, examples such as: "GET - Browses
the first message on a queue. In line with the HTTP protocol this does
not delete the message from the queue".
However, there some obvious problems with the design (possibly due to
simplifying clients), most of which has already been discussed in this
* DELETE to retrieve a message is done on the queue URL
* DELETE to browse a message is done on the queue URL
* No support for retries if a POST or DELETE fails
* A custom header (x-msg-format) that overrides Content-Type, not sure
if this is really an issue
* No description of how caching is handled. Examples does not contain
any cache headers at all so I'm guessing that it's not supported at all.
What do you think if their design, judging from this thread this seems
to be an tricky area?