Re: Traditional RPC
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.   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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format