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

Keith,

Here is a link to an interesting presentation from Roy T. Fielding
regarding the evolution of various architectural styles:
http://www.ics.uci.edu/~fielding/talks/webarch_9805/index.htm

I think that there are 4 important points that have been highlighted in
this discussion:
- we need to acknowledge the fact that we are solving a new class of 
  problem that is more about machine-to-machine communication.

- we need to make sure that the adopted architecture style
  is developer friendly because at the end of the day developers 
  will be the ones who program web services (not user agents).

- we need to overcome the fact that APIs/RPC are difficult to compose in
a
  reliable and adaptable fashion and they do not represent information
  very well.

- we need to learn as much as possible from the strength and weaknesses
  of previous architectural styles.

The solution is not obvious but I think that going back to the basic API
based client server model would probably end up resulting in a failure.
We need a model that can scale, represent information well and adapt
reliably to continous change.

Edwin


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Keith Moore
Sent: Monday, April 15, 2002 7:38 PM
To: www-tag@w3.org
Cc: David Orchard; www-ws-arch@w3.org; xml-dist-app@w3.org
Subject: Re: FW: draft findings on Unsafe Methods (whenToUseGet-7) 


> 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 Tuesday, 16 April 2002 00:34:59 UTC