protocol7

As has already been reported in several blogs, IBM has released a new supportpac for exposing WebSphere MQ queues and topics as HTTP resources. The supportpac aims at being RESTful, at least that’s what you are lead to believe from the banner on the main WMQ site.

However, much like the ActiveMQ REST support, the RESTfulness, or even basic HTTP compliance does have it’s rough edges.

The supportpac exposes a queue on a URL looking like http://example.com/wmq/msg/queue/FOO. On this resource, three basic operations is allowed:

• POST: will push a new message to the queue
• GET: will peek at the first message from the queue
• DELETE: will pop the first message from the queue

Now, there are several problems here. For example, the GET and DELETE is done at the queue URL, but actually works on a different resource, the message. The way the DELETE is done, the expectation would be to remove the queue itself. And the GET should return some representation of the queue, such as a listing of the available messages. On top of this, DELETE must be idempotent, however in this case, doing multiple DELETEs will result in very different results (different messages being read). In addition, re-doing a failed DELETE (for example due to being in-doubt because of a network failure) could lead to multiple messages being lost (note that IBM makes it clear that this is the case).

All that being said, as been shown on rest-discuss lately, designing a queue with the standard HTTP methods is not entirely straight-forward and might lead to a both complex and odd (from a queuing perspective) API. Adding simplicity in the mix, and not supporting assured delivery, the design chosen in the WMQ supportpac might be understandable.

Besides the issues above, I think a big improvement to the API would be if it supported resource discovery. The examples below describe this, in addition to suggesting a better design for pushing, peeking and popping messages:

• http://example.com/wmq returning a list of the available queue managers
• http://example.com/wmq/myqm returning a list of the available destinations on that specific queue manager.
• As discussed above, the http://example.com/wmq/myqm/queue/FOO resource should return a list of available messages on that specific destination. This resource also supports the POST as described above.
• http://example.com/wmq/myqm/queue/FOO/nextmsg redirecting to the first message of the queue
• http://example.com/wmq/myqm/queue/FOO/123456789 identifying a specific message and supports the GET and DELETE requests as described above.

In a comment on an earlier post here, James Strachan of ActiveMQ notes that he would like to design a fully RESTful API for ActiveMQ. Maybe that could be a chance to dive deeper into this interesting area.

As noted on the Hursley WMQ blog, IBM is looking for feedback on the code, so hopefully some of these issues could be taken care of.