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

Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)

From: Keith Moore <moore@cs.utk.edu>
Date: Mon, 15 Apr 2002 23:38:03 -0400
Message-Id: <200204160338.g3G3c3x05892@astro.cs.utk.edu>
To: www-tag@w3.org
cc: David Orchard <dorchard@bea.com>, www-ws-arch@w3.org, xml-dist-app@w3.org
> It is a common misconception by Web services proponents that HTTP is
> nothing more than a transport protocol which moves bits from A to B,
> where A is typically a web server, and B is typically a Web browser.  It
> should come as no surprise that because of this view, it is felt that
> HTTP and the architectural style that describes it (REST) is
> insufficient for program to program communication.  This could not be
> further from the truth.
> 
> Anything that can be done with other architectural styles, such as
> message passing, RPC, tuple spaces, etc.. can also be accomplished with
> REST.  It just has to be done in a different way.  The common use of Web
> services, upon which you are bumping up against with this complaint, is
> not REST and is not the Web.  It is attempting to use a different
> architectural style, RPC (or some derivative), that has repeatedly
> demonstrated its inability to be deployed on the Internet (ONC, CORBA,
> DCOM, RMI).

my guess is that lots of people will continue to treat HTTP as an RPC 
mechanism no matter what architecture you promote.   for that reason 
alone it's silly to claim that RPC has not demonstrated the ability 
to be deployed - HTTP as it is often used is a wildly successful 
(in terms of amount of deployment) realization of RPC.  the RPC paradigm 
is more familiar to most programmers than REST, and it's probably
easier to understand than REST, and it will be difficult to overcome 
that inertia.

Keith
Received on Monday, 15 April 2002 23:38:10 GMT

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