Altova Mailing List Archives


Re: [xml-dev] Traditional RPC

From: Mike Champion <mc@-------.--->
To: xml-dev@-----.---.---
Date: 2/17/2002 10:02:00 PM
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.

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.