W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

REST vs the rest and other angels on pinheads

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Fri, 20 Sep 2002 10:09:22 -0700
To: www-ws-arch@w3.org
Message-Id: <B555DB7E-CCBB-11D6-8E9B-000393A3327C@fla.fujitsu.com>

I believe that part of the underlying problem with the seemingly empty 
debate on what is a web service is that we are approaching this from a 
bottom-up perspective: we have a bunch of technologies, and a bunch of 
people (ab)-using the technologies to get their work done and now we 
are supposed to come in after the fact and decide what is REALLY going 

Seen from the bottom, it can be very hard to distinguish different uses 
of technologies and it can be very hard to distinguish what is of the 
essence. This gets worse not better when people believe that they have 
been successful in their technology choices.

Hence the endless debate about the PROPER definition of a web service 
and other angels on pinheads.

Of course, the W3C itself is founded on a technology POV.

There is clearly something to be gotten from the success of the web; 
but surely people recognize the difference between humans talking to 
humans mediated by computers and computers talking to computers. So the 
success ingredient that web services takes from the general web is not 
likely to be something as trivial as HTTP/GET/POST but some deeper 

If we take a top-down POV of web services, then, at the 50K' level the 
particular deployment technology is not likely to figure that highly: I 
want my computer and your computer to get together and get their 
`thing' done so that I can get on the next flight outta here; or our 
companies want to make sure that our accounting systems are 
appropriately integrated.

 From this lofty altitude, one might argue that a standardized interface 
and a simple approach to combining technologies is at the heart of the 
success of the WEB: i.e., its the fact that all browsers know how to 
get and render an HTML page and also how to identify the appropriate 
helper application when they get a data source that they can't render. 
For the WEB the standardized interface meant HTTP/HTML/GET mostly (with 
the CGI extension coming later).

However, as any programmer will tell you, making sense of human 
readable text is difficult and a waste of time if you know that you are 
talking machine-to-machine. We need a different set of solutions for 
web services than for web pages.

I propose adopting an essentially top-down approach to the WSA -- 
figure out what is needed and then figure out how to deliver. 
Realistically, of course, you need a mixture: an informed top-down 
approach where we take into account the current technological 
possibilities (i.e., no magic here please).

That way, if we do discuss REST in the WSA spec itself, it from the 
POVs of our requirements and of what useful lessons are there in there 
for us to benefit from.

Received on Friday, 20 September 2002 13:09:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:59 UTC