RE: REST; good for humans and machines

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Sunday, January 05, 2003 12:41 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: REST; good for humans and machines
> 
> 
> > Uhh, maybe a year ago this would have surprised many of us. 
>  The REST meme
> > is in pretty wide circulation now.  I think we're also coming to an
> > understanding that the "REST is for humans" thing is a red 
> herring; the
> 
> Really?  I keep hearing it over and over, even in this recent
> discussion.

See below.

 
> Exactly.  Which architectural style has the necessary properties?
> 
> We know REST does, because the Web demonstrates that.

It's precisely this repeated assertion that leads to the "red herring" that
REST is for people and irrelevant to Web servces, IMHO.  It's you who are
saying that the REST architectural style (presumably without some sort of
out-of-band agreement over standard schemas and semantics) is good for
machines.  This leads to the riposte that this is only DEMONSTRATED to work
when there is a human at the other end who can do something useful with the
raw representation of a Web resource.  We can IMAGINE this working with
machines at both ends, but only if the representation is highly constrained
by shared schemas, WSDL descriptions, RDF knowledge bases, or whatever.  

So, I'll clarify what I said earlier:  If the representations being passed
around are being processed by humans, the REST interfaces are sufficient --
they just have to deliver the information, and the human reads it (or fills
out the form, or finds an appropriate hyperlink, or whatever).  If the
representations are being processed by machines, additional interface
constraints are necessary.  Somehow or other, if we want the last trade
price of IBM's stock in dollars, we have to specify that unambiguously, we
can't assume that the human will pick the right company from a dropdown list
or scan through a list of links to find the right one to click or plow
through a table of results until the desired one is found.  There are all
sorts of ways to do this using HTTP and XML - HTTP parameters, URIs that
encode the information, POSTing SOAP messages ... but they have to be
specified.  

My contention is that it is the COMPLETE SPECIFICATION of the data passed in
each direction that constitutes the "interface" to a web service, RESTfully
or non-RESTfully, so it is misleading to say that REST provides a uniform
interface for web services.   That doesn't mean that RESTful web services
(with additional constraints specified by RDF or whatever) aren't a Good
Thing, just that their superiority needs to be be demonstrated by something
other than the analogy to the Web.  I just can't get worked up over the
distinction between POSTing a getLastSharePriceOfIBM message and GETing a
http://www.stockquotes.com/ibm/lastshareprice resource. There are advantages
and disadvantages of both -- the former is easier to automate, leverages XML
more readily, avoids URI encoding issues ... the latter is hyperlinkable,
cacheable, more easily integrated with the human-oriented web, etc.  I take
the rather quixotic job of replying to this permathread because I'd love to
see a detailed enumeration of the advantages and disadvantages so that we
can put them in the WSA document.

Received on Sunday, 5 January 2003 12:47:25 UTC