Comparing REST API’s: Windows Azure Queue Service vs. Amazon Simple Queue Service (SQS)

Keith Bauer Photo

A recent customer engagement prompted me to share details regarding a comparison of the REST API’s used to manage the Windows Azure Queue Service and the Amazon Simple Queue Service (SQS). As expected, these services both provide similar types of message queuing functionality for their respective platforms: create queues, delete queues, send messages, retrieve messages, etc… However, what is not typically expected is the fact that Amazon’s SQS service does not support a REST API. As stated in the 2009-02-01 SQS migration guide, “the REST API is not available”.

This wasn’t always the case. In fact, the Amazon SQS used to have a REST interface which provided all of the basic message queuing services. This was originally provided in their SQS API version 2006-04-01 as well as in their SQS API version 2007-05-01, both of which have been superseded by a newer API which no longer provides a REST interface. Figure 1 below illustrates how the REST API’s used to compare to one another.

image
Figure 1 – REST API for Common Queue Service Operations

Implications

Contemplating the differences between these REST API’s is now a moot point. If you are steadfast on using a REST architectural style for your cloud-based message queuing needs then the Windows Azure Queue Service should provide what you are looking for. However, to be fair, even though Amazon’s SQS REST API is no longer available, they do support other methods which use simple HTTP/HTTPS requests and provide all of the same functionality as their previous REST API. One of the methods used to manage SQS today is the SQS Query API, which uses both GET and POST methods. Although similar to REST in many ways, the SQS Query API does not adhere to all of the guidelines of a REST architecture style, as defined in the often referenced dissertation by Roy Thomas Fielding. Optionally, you can leverage the SOAP protocol for making SOAP requests and calling SQS service actions. This, however, is only supported by Amazon over an HTTPS connection.

Note Note

The Amazon SQS REST API is no longer available. SQS service management is provided via the SQS Query API, or SQS SOAP API.

Some of you may be wondering, if the SQS Query API uses HTTP/HTTPs coupled with GET and POST methods, then why is this not REST? Well, for starters, the SQS Query API does not represent a resource as a URI. This violates one of the requirements for calling an API a REST API. However, if you are in the camp of people which accept various levels of REST (i.e. level 0, 1, 2, 3), then according to the Richardson Maturity Model as a way of measuring the restful maturity of a service, the SQS Query API can arguably be considered a Level 0 REST interface. Although, Roy Thomas Fielding, the individual known for coining the REST term, would likely not call anything a REST API until at least a Level 3 interface has been achieved.

Summary

The purpose of this article is not to debate whether REST is good or bad, or to determine if a service which supports a REST API is any better or worse than the other. Rather, this should provide clarity that the Windows Azure Queue Service leverages a REST API, while Amazon’s Simple Queue Service (SQS) leverages the SQS Query API, as well as a SOAP API. Hopefully this brief synopsis has provided some bit of useful insight with the necessary background for better understanding how these common cloud-based message queuing solutions are managed.

Resources and References

Windows Azure “Queue Service API” article in the MSDN Library

Amazon Simple Queue Service “Developer Guide – API Version 2006-04-01” PDF

Amazon Simple Queue Service “Developer Guide – API Version 2007-05-01” PDF

Amazon Simple Queue Service “Developer Guide – API Version 2008-01-01” PDF

Amazon Simple Queue Service “Developer Guide – API Version 2009-02-01” Online

Dissertation by Roy Thomas Fielding

Richardson Maturity Model

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 1.00 out of 5)

One Comment

  1. Pingback: Distributed Weekly 96 — Scott Banwart's Blog

Leave a Reply