Overview of REST-* Messaging Draft 4
Posted by billburke on November 19, 2009
Just finished draft 4 of REST-* Messaging. Please check our our discussion group if you want to talk more about it. Here’s a list of resources and their corresponding relationships for a high level overview. See the spec for more details. It relies heavily on Link headers. The current draft shows a lot of example HTTP request/responses to give you a good idea of what is going on.
Destination
A queue or a topic resource.
Relationships:
- post-message – link to POST/create a message to a queue or topic. This can be
- post-message-once – link to POST/create a message to a queue or topic using the POST-Once-Exactlly (POE) pattern
- post-batch – POST/create a batch of messages using Atom or Multipart
- post-batch-once – POST/create a batch using the POE pattern.
Message
Every message posted creates a message resource that can be viewed for adminstration, auditing, monitoring, or usage.
Links Relationships:
- reply-to. Destination that you can reply to
- reply-to-once. Destination that you can reply to once using the POST-Only-Once pattern
- reply-to-batch. Destination that you can reply with a batch of messages
- reply-to-batch-once. Batch using POE.
- next. If pulling from a topic, messages will have this link. This is the next message after this one.
- acknowledgement. If pulling from a queue, this link allows you to change the state of the message to acknowleged or not.
- generator. Destination that the message came from
Topic
Has the same links as Destination with these added:
Link Relationships:
- next. GET the next incoming message. Clients should use the Accept-Wait header to set a blocking timeout (see later).
- last. Last posted message to the topic
- first. First message posted to topic, or, the first message that is still around.
- subscribers. URL that allows you to view (GET) or create/register (POST) a list of URLs to forward messages to.
Queue
Same as Destination, but these additional link relationships:
Link Relationships:
- poller. Alias to the next available message in the queue. Returns a message representation along with a Content-Location header pointing to the real one. a POST is required to access this because the state of the queue is changed.
- subscribers. Same as topic push model.
Alejandro Montenegro said
Hi Bill, it looks very interesting your proposal, I will give it a deeper look to see if I can give any suggestions.
I know the HornetQ team plans to implement a REST interface, are you already implementing this? if so anywhere I can check out the source, would be glad to contribute.
billburke said
Alejandro, yes, I’ve started prototyping, but the code is *very* prototype quality (band-aided together just to test the interface). http://resteasy.svn.sourceforge.net/viewvc/resteasy/trunk/rest-star/messaging/
Some changes to HornetQ would be needed. I’ve discussed it a bit on the HornetQ forum.