« Why Lisp will be around for another 50 years | Main | XMPP Basic IM Protocol Suite »

REST, URIs and Queues

Using a URI API instead of WSDL/SOAP doesn't neccesarily mean one has a RESTful system. Despite claims, the Amazon API is arguably not RESTful as a result of hiding the method in the URI. For example in the Amazon queuing API has a delete operation that looks like this :

http://webservices.amazon.com/onca/xml?Service=AWSSimpleQueueService
    &SubscriptionId=[Your Subscription ID Here]
    &Operation=DeleteQueue
    &QueueName=[The Queue Name]			

The HTTP method does not seem to be specified. Hopefully an operation with side-effects, like delete, is not going to be applied over GET. HTTP has a DELETE method, tho' given the limitations of some clients, POST might be an acceptable compromise.


Let's not be too quick to jump on Amazon. In general, using URIs to modelling containers is known to be tricky. I'm working on a reliable receive technique for HTTP; a technique for reliable delivery has already gone in production. One use case for these techniques is that one could provide a queuing interface or gateway to systems based on JMS or MSMQ - arguably offering similar functionality to the Amazon service, but with different levels of service. My suspicion in working on these is that there is a mismatch between HTTP and queuing data structures that makes implementation matters less simple than we would like. A queue, well, is a queue. However HTTP URI space is more like a big hashtable than a queue - assuming you have the URIs to hand, then everything on the web is click away.

This mismatch also rears its head in syndication technology - we can think of RSS feeds as a means of generating a list of URIs and putting that list in a well known place. There is an argument that says the data structures implied by HTTP or Tuplespaces can offer more than queuing structures; however that neglects the fact there are a lot of of systems we'd like to web enable and integrate that are based (and happily so) on message queuing technology. Other approaches to container modelling incude WebDAV, but the RSS/Atom "here's-a-list-of-items" seems to be an expedient solution for bridging web and message queuing systems.


November 10, 2004 03:00 PM

Comments

John Wilson
(November 10, 2004 04:02 PM #)

Bill,

I have just finished hacking a Groovy library which supports all of these operations using the "REST" API. They all use GET.

Dan Hatfield
(November 11, 2004 11:31 PM #)

Bill,
Care to elaborate on your comment -
"There is an argument that says the data structures implied by HTTP or Tuplespaces can offer more than queuing structures"

Are you talking about different data structures to support the different types of querying you might see against a tuplespace vs a queue?

I'm hoping you can clear up some confusion for me - between tuplespaces and topic based message queues. For instance, projects like ActiveSpaces at codehaus definitely muddy the waters in distinguishing between the two. The main difference I see is in the querying mechanism.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1428