This document is intended to document the ideal RESTful interface to message queues in light of
One of the main issues with making a truly RESTful API to a message queue is that a message queue is essentially a load balancer, so each consumer of a queue sees essentially a different queue; as only one consumer gets a copy of each message.
Also if a consumer goes away, the messages that were associated with that consumer need to be re-assigned to another consumer. So the main tricky part really is the operation for a consumer to find out what messages it may consume.
This section deals with the general browsing and creation/deletion of queues.
To browse the queues, they are a hierarchial structure usually, so lets browse them like any APP collection
Note that we could expose the queues as a tree, for example
Creating a queue is typically idempotent; since really you are just creating a name that folks can post to.
Sending to queue is the usual APP-style double request; one to get the unique URI to post to and secondly to do the actual post...
The client can then repeatedly POST the mesage to someUniqueUrlForTheNewMessageToBePostedTo until it gets a 200 OK which avoids duplicates.
If a smart client is capable of generating a system wide unique GUID (id) for the message, the server side could ignore duplicates. So posting to queue could be done without the double-request approach above
As described above, this is the tricky part of mapping message queues to REST.
So we introduce a resource for a subscription to a queue. The subscription remains active until some timeout value - so a subscription is a sort of lease.
When a subscription is created it can be given a variety of different pieces of data such as
The actual subscription data could be form encoded key/value pairs.
Good clients will delete subscriptions when they are no longer required; though they do timeout eventually.
You consume messages by browsing the subscription (like any APP resource) then DELETEing the message when you have finished processing it.
Then to acknowledge a particular message has been processed
Almost all of the above could be just pure APP really. The only real difference is that each consumer has its own feed of messages which are to be consumed.
In ActiveMQ's case, we use a prefetch value per consumer to define how many messages each consumer gets in its buffer, before messages must be acknowledged to get more messages.
So the idea is that we have a per-consumer feed which is created; it can then be browsed (by anyone with sufficient karma).