On Dec 11, 2006, at 12:03 PM, Steve Jones wrote: > 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. > Yes, but not in a formal (machine-readable) way. That was the point of our discussion, wasn't it? I can't recall whether somebody else did, but I never claimed there was no need for documentation. I just argued that IMO, machine- readable documentation is not as crucial as you seem to believe. > > > > 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. > > I notice that you have ignored these two lovingly composed paragraphs ;-) > > 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'm all *for* improving upon this, but I certainly don't see how Web services (and the programming models of all known Web services stacks) are an improvement. Statically generating stubs and skeletons from WSDL is something I advise against even when wearing my WS-* consultant's hat. > > 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". > > You ignored this paragraph, too, even though it's about my third try to get the point about application semantics across. REST is less specific than a WSDL, but way more specific than just moving messages around. > > 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". > No, it does not apply to REST as well. That's the point I and others have been trying to make in this thread all along. > 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. > Sure, I can see how the vendors support WS-* for altruistic reasons only.
Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
