- From: Keith Moore <moore@cs.utk.edu>
- Date: Mon, 15 Apr 2002 23:38:03 -0400
- 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:11 UTC