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....
Previous Topic
