[
Lists Home |
Date Index |
Thread Index
]
2/17/2002 2:09:40 PM, "Dave Winer" <dave@userland.com> 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.
|
