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

RE: REST; good for humans and machines

From: Newcomer, Eric <Eric.Newcomer@iona.com>
Date: Sun, 5 Jan 2003 10:02:20 -0500
Message-ID: <DCF6EF589A22A14F93DFB949FD8C4AB2916F68@amereast-ems1.IONAGLOBAL.COM>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>

I think that if the REST folks had designed Web services, they would be different, but then again, HTTP-NG was different, and so was HTTP-EF, and neither gained widespread acceptance.  Nor did ICE, XML-RPC, and about a dozen other XML protocol proposals.

So yes, certainly I think everyone can agree that theoretically you could design and implement pretty much equivalent functionality using HTTP without SOAP and WSDL, but the larger, and very much more difficult problem is how do you ensure market acceptance?

Some of us may not think SOAP and WSDL are pretty (I for one think WSDL is pretty ugly, but it's nonetheless an improvement over its precursors, SDL and WASSL) but let's at least acknowledge the acceptance issue when discussing alternatives.

I know that many of you remember very well about three years ago when the adoption of SOAP was very much up in the air.  And many of you no doubt remember the COM vs CORBA wars of the mid-90s.  If the industry had been able to agree at that time upon a single RPC standard, CORBA would have been much more widely adopted and therefore more widely successful, perhaps even becoming the standard for "Web services" as many felt it should.   (And by the way, CORBA folks think anyone who'd use HTTP for any kind of distributed computing is nuts, and I'm sure we could drum up an equally endless religous argument about why IIOP is superior to HTTP and should have been adopted, as was once proposed, as an Internet standard. Then we wouldn't have all these issues with HTTP...) 

So let's please at least acknowledge this very real, non-technical issue since we can debate the tecnical merits, opinions, and viewpoints endlessly and still not be able to predict or control the market and how for whatever combination of reasons a spec ends up gaining widespread support.  

One other thing, although I know this is probably asking for too much -- it would be nice if we could also acknowledge that there are no "objective facts" in this discussion since by definition we cannot understand what we don't understand, and every human brain, as every human, is imperfect. There is no absolute, objective truth since to know it we'd have to be non-human.


-----Original Message-----
From: Champion, Mike 
Sent: Saturday, January 04, 2003 6:09 PM
To: www-ws-arch@w3.org
Subject: RE: REST; good for humans and machines

> -----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 Sunday, 5 January 2003 10:02:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC