.NET Services REST Queue Protocol

, Apr 3, 2009

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.

On April 6, 2009 9:22 AM, anonymous coward said:

Perhaps of interest


This document describes RestMS, a RESTful Messaging Service that exposes AMQP networks as a set of resources clearly identified by URIs and each supporting the appropriate HTTP methods. RestMS is designed to interoperate with AMQP/0.9.1 and future versions of AMQP.

On April 6, 2009 9:58 AM, Stefan Tilkov said:

Thanks, this is the first time I heard about it and it looks very interesting.