.NET Services REST Queue Protocol

Clemens Vasters:

Here is the Service Bus Queue REST protocol. I apologize if this is a bit dry, but I want to give you the bare protocol facts first and will follow-up with code samples later. […] The beauty of REST is that there’s a uniform interface. It’s all just GET, POST, PUT, DELETE, a set of resources, and a rigorous application of the RFC2616 / HTTP 1.1 rules. That doesn’t make the description particularly entertaining, but it does yield a pretty consistent interaction model.

After a quick read, many things that I like, only a few that I don’t (read Clemens’s description first to make sense of these comments):

• Putting a password in the URI to get an identity token seems to expose information unnecessarily
• Queue creation seems fine, even though I feel a little uneasy about wrapping this in an Atom entry
• On the other hand, Atom seems reasonable considering you get an Atom feed from the queue’s “parent” resource
• Very nice to see the use of link/rel to get to the detailed Queue URIs; it would be even better if the rel values themselves were URIs in an MS namespace
• Queue renewal/deletion seem fine to me
• Using “alternate” for the tail seems strange
• “The queue’s tail endpoint accepts requests with any HTTP Content-Type and any HTTP method except GET, HEAD, and OPTIONS.” The tail does not accept GET. Why not? Can’t think of a reason. Also, I don’t get why any method is allowed. It seems to me a POST/PUT combination or an idempotent POST variant would be the way to go.
• “DELETE performing a destructive read” – huh? What happens if I don’t get back a response? How can I retry (as I can’t tell whether I get the same or a different message)? Maybe it’s intended to be used only if you don’t care about losing messages.
• The POST lock/delete approach, on the other hand, is very nice. Maybe it should be made idempotent, again e.g. using POE
• “The Delete request is sent without any entity body and MUST have a Content-Length header that is set to zero (0)”; although my immediate reaction was to question whether DELETE ever carries a body, the HTTP spec indeed doesn’t say anything about this
• “The DELETE and POST operation have a set of options that are expressed as query parameters appended to the queue’s head URI” - the wording is worse than the actual approach.

All in all, pretty nice, and much better than Amazon’s “Query” API for SQS.