W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: REST; good for humans and machines

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Sat, 4 Jan 2003 16:08:51 -0700
Message-ID: <9A4FC925410C024792B85198DF1E97E404B6D453@usmsg03.sagus.com>
To: www-ws-arch@w3.org



> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Saturday, January 04, 2003 5:30 PM
> To: www-ws-arch@w3.org
> Subject: REST; good for humans and machines
> 
> 
> 
> That REST was believed for humans is, as I understand it, why Web
> services were created in the first place.  If it's also for machines,
> then what we've got here is two ways of solving the same problems.

What's the other way ... certainly you're not lumping all things non-RESTful
into one category?  There would appear to be a myriad of ways of solving the
same problem.

> 
> At the very least, this should come as a surprise to the WSAWG, no?
> Thoughts?

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
question of how one imputes the semantics of a web page or web service
invocation is orthogonal to the question of the architectural style.  Still,
somehow or other the contents of a message have to be mapped onto something
that a machine can understand.  The "classic" SOAP/WSDL paradigm does this
more or less mechanically, trusting some human programmer to make sure that
the functions and arguments "mean" the same thing on both ends.  REST,
AFAIK, simply says nothing at all about this.

I think it's pretty clear to most who have followed the "REST vs whatever
the alternative is" megathread that one can build a RESTful solution to just
about any distributed computing design problem.  One can also (I think)
built an RPC, or asynch document messaging, or tuple space, etc. etc. etc.
solution to just about any distributed computing design problem.  This
leaves us with a number of questions that don't seem to have clear answers
at the moment:

- Which of these is most likely to be optimal under different scenarios
(different networking environments, user requirements, assumptions about
homogeneity, availability of out-of-band discovery mechanisms ....)?

- How can we conceive of the components and interrelationships in a web
services architecture that allows various features to be re-used in
different applications with different architectural styles?
Received on Saturday, 4 January 2003 18:09:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT