On 11/12/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
Damn you've stopped me using that against you :) > > A good example (IMO) of a RESTful API is Blinksale's: > > http://www.blinksale.com/api Which is great, but he is still documenting it. > > 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. But in 2006 should we still be doing this? Isn't it time to move programming up a level? Java was an improvement over C++ because it got rid of memory management challenges and now it finally has decent async libraries. I'd like to see this distributed applications environment push the bar up again, rather than trying to concentrate on base programming. > 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. Still trying to see it, right now its in the XP camp for me. I'd like to see the time spent on things like WS-TX et al spent on a WS-Contract or WS-SLA, which would help businesses today and would improve on the systems and standards that we have. > > 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. Java sucks too (as does C#). Why didn't Eiffel survive? My father's comment on seeing WS for the first time (and it applies to REST as well) was "30 years and we've finally made it to ASCII RPC". Personally I think we'll see more vendors start "supporting" REST because this enables them to keep pushing out the same old technologies with a different face, rather than try and develop new an innovative tools that try and solve business, rather than technology, problems. > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > >
