On Dec 11, 2006, at 10:39 AM, Steve Jones wrote: > And of course its exactly what Amazon do to help people use their REST > APIs (http://docs.amazonwebservices.com/AmazonHistoricalPricing/ > 2005-10-19/)
I don't find these interfaces particularly RESTful, e.g. all the talk of operations clearly shows someone is missing the point. A good example (IMO) of a RESTful API is Blinksale's: http://www.blinksale.com/api I can easily imagine a Web Services API that offers access to the same functionality. If I follow your reasoning, this would be much, much better -- in fact, it would work, as opposed to the REST API, which would not -- because the WS API would offer a WSDL. I simply don't agree -- the documentation would look slightly different, but I see no reason why you would find one of these solutions absurd. Both would work. But they have different characteristics. For example, I can get a list of invoices from Blinksale by issueing a GET. If I do this from my browser, I get an HTML representation. If my client program sends application/vnd.blinksale+xml as the content type (note that this one is particular to this specific application), I get XML (as described in the documentation; sadly without a schema, although it would obviously be easy to add one and link to it from the documentation). If I use application/atom+xml, I get back an Atom feed - one that I can subscribe to in my newsreader. I can send you an email including a link to a particular invoice -- and you can retrieve its contents by issueing a GET. This means that using only a standard HTTP client library, I can do lots of things programmatically. For example, I can combine the results of my own REST APIs with ones from Blinksale (by using links). Remember a dereferenceable link can "point" everywhere, so I can integrate information from a variety of sources. If my client program requests a particular invoice, it might receive a 404 response code -- which it will know how to handle in a generic way because this is part of the HTTP standard. It might also receive a 301 (Moved Permanently) even though this is not even described in the Blinksale docs -- but it will know what to do (never request the resource at that URI again, but at the one returned in the 301 response). The key REST idea I'm trying to illustrate is that there *application semantics*, even though they might be called generic, that are specified as part of the protocol. A POST to a resource will mean different things in different applications, but you have at least some information - e.g. that it's neither guaranteed to be "safe" nor "idempotent". I strongly believe (after a long, long time of thinking different) that the time and effort invested in the WS-* specs, standards and products would have been much better spent on supporting, expanding and improving upon the ideas of REST and HTTP, which is nowhere near perfect, but IMO much better suited for the dynamic, loosely-coupled, fault-tolerant landscapes of the future. And one significant piece of evidence I see is that more and more former WS proponents become more and more intrigued, interested, and finally convinced in REST's value. Is REST a silver bullet? No way. If I had to build a transactional banking application accessed from application clients, I'd be likely to end up using J2EE, XA transactions, RMI for communication, and even Entity Beans for persistence. CORBA is a great technology as well, as are messaging systems (JMS-based or not). I continue to use WS-* as well - in fact, I spend a lot more of my time with this than with any of the other technologies currently. It just happens that it is the one I like the least. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
