[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Traditional RPC

• To: xml-dev@l...
• Subject: Re: Traditional RPC
• From: Mike Champion <mc@x...>
• Date: Sun, 17 Feb 2002 16:51:13 -0500
• In-reply-to: <060701c1b7e6$a6d4f5a0$33a1dc40@murphy>

2/17/2002 2:09:40 PM, "Dave Winer" <dave@u...> wrote:

>The big difference between "Traditional RPC" (whatever that means) and REST
>is that there are toolkits for T-RPC for every language and environment
>known to man. [1] [2]

Uhh, every language and envrionment that supports HTTP supports 
REST out of the box, no additional layers needed.  In the context
of the Web as we know it, REST is a way of *using* HTTP directly
in an application rather than hiding it behind a toolkit.

It's true that "traditional" programmers will find
some flavor of RPC over XML and HTTP more convenient as a way
of communicating between what you call "full peers".  Nobody is
suggesting that XML-RPC/SOAP RPC is "bad", there are a lot
of good use cased (e.g., the way your users can access services 
on one anothers' sites). That's fine, especially since no
money will be lost or bombs dropped if my weblog can't get 
get the greeting of the day or whatever from your site.

The REST argument is simply that it:

- requires nothing on top of HTTP;
- scales to the full internet full of unreliable connections,
non-server devices, high latency, etc. better than RPC
without additional infrastructure investment or "reliable"
protocols
-  leverages existing investments in search engines for discovery,
cacheing for performance optimization, the universality of the
URL/URI namespace, etc.

So, if you want to make your web services easily accessible to 
programmers who don't have to worry about the plumbing and 
just want to call a function and get a result, use RPC.  
If you want to make your web services scalable and reliable
using the Web as it exists today, at the cost of making the 
programmers think about HTTP and asynchronicity, use REST.

> REST seems to have found a home in debates on XML-geek mail lists

This is not a new religion that some geeks are evangelizing.
Everyone who GETs a URL is using REST; it was a design principle
of HTTP and we have all been "speaking REST all along without 
knowing it." The only reason that the geeks are worrying about
it now is because, after much discussion, is it becoming clear
that the architecture of POST-ing an XML document to trigger
a service and getting the result of the service back from the 
response to the POST request
does not confer the same architectural advantages that
GET-ing a URI to trigger a service (and having a variety of
options to retrieve the result) does.  If you think of HTTP as
just a way of sending data around between applications, the 
distinction is trivial.  If you think of HTTP as a well-proven
architecture for reliable computing, it is signficiant, because RPC
forces some higher level of software to re-invent a lot of 
stuff that The Web offers "for free".  Paul Prescod's recent
XML.com article has a nice discussion of this with respect
to REST vs UDDI as a service discovery mechanism.

That's my understanding anyway; Mark B. or Paul P. may wish to
to set me straight if I've missed something.

• Follow-Ups:
  • Re: Traditional RPC
    • From: "Dave Winer" <dave@u...>
  • Re: Traditional RPC
    • From: Gavin Thomas Nicol <gtn@r...>

• References:
  • Traditional RPC
    • From: "Dave Winer" <dave@u...>

• Prev by Date: reminder: call for papers, XTech/O'Reilly Open Source conference
• Next by Date: Re: Traditional RPC
• Previous by thread: Traditional RPC
• Next by thread: Re: Traditional RPC
• Index(es):
  • Date
  • Thread