[
Lists Home |
Date Index |
Thread Index
]
I knew you were going to say that! (I've been listening. ;->)
That's why I said let's get some apps out there and let's roll.
BTW, last time I checked HTTP was synchronous.
Maybe I missed something.
Dave
----- Original Message -----
From: "Mike Champion" <mc@xegesis.org>
To: <xml-dev@lists.xml.org>
Sent: Sunday, February 17, 2002 1:51 PM
Subject: Re: [xml-dev] Traditional RPC
> 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.
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
