[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Traditional RPC
Paul those are good compelling points, had they been raised before we built an infrastructure for XML-RPC and SOAP at the script level. Earlier this month we finally implemented the top of the stack, something called SCNS or Simple Cross-Network Scripting, which makes calling a web service as simple as calling a procedure (yes it looks a little different, and that's good, imho, people should know when they're making a networked call. And before someone says Python had it before us, let me say that Python had it before us. ;-> Also I really appreciate the offer to convert Manila-RPC to REST, but let's look forward. I'll keep my eye open for an opportunity to use your principles in putting together a new service, and I'm sure it'll be easy and perform well. How does that sound?? Dave PS: I'm doing a new centralized app now, it's all web services, and it's a good mix of plain old HTTP, XML-RPC and SOAP. And a few other things too. ----- Original Message ----- From: "Paul Prescod" <paul@p...> To: <xml-dev@l...> Sent: Sunday, February 17, 2002 2:11 PM Subject: Re: Traditional RPC > Dave Winer wrote: > > > > I've been following this debate from the sidelines and finally thought it > > was time to chime in. > > > > 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] > > REST is a technique, not a bit of software. You've already built a > business around sophisticated uses of that technique. The fundamental > idea is that every important data object should have an address so that > it can be referenced. When you apply that technique to human > communications you get Blogging. When you apply it to machine to machine > communications you get a much more powerful type of web services. > > As applied concretely, REST consists two things: URIs and HTTP. When it > is applied to machine to machine problems it usually also consists of > XML. Any language that has support for these three technologies has > support for REST in general and XML+REST in particular. So support for > REST is required before XML-RPC can be implemented. > > Web Bugs in XLM is an excellent application of REST: > > http://scriptingnews.userland.com/backissues/2002/02/17#webBugsInXml > > Note how I referred to it with a URI. (my only suggestion is to make the > "ping" a POST, not a GET to use HTTP semantics correctly and avoid > miscounts due to caching). Another interesting thing about this > application is that it is a perfect example of Asynchronous HTTP, which > many people mistakenly claim is difficult or impossible. > > > REST seems to have found a home in debates on XML-geek mail lists, and > > occasionally at conferences and on O'Reilly's websites. > > Oh yeah, and on every website that exists. > > > If you want to have a revolution, our software will adapt [3] perfectly to > > it, let's get some apps, and let's rock. > > Your software doesn't really have to adapt. You don't need new apps. > Meerkat uses REST heavily. When it wants to get information from > scripting news to aggregate it, it doesn't call an RPC API, does it? It > just uses HTTP to fetch some XML. When I want to integrate some Meerkat > information into my site I also don't have to call an RPC API. > > I just do this: > > http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer > > I think it is amazing how I can refer to this resource in a totally > programming-language and environment independent way. Whereas, let's > consider the RPC equivalent: > > ServerProxy("http://www.oreillynet.com/meerkat").GetArticles("Dave > Winer") > > This isn't syntactically correct Perl or C++ or ..., so it has to be > translated to each language. I can't use it in a standard web browser. > Wget doesn't understand it. I can't make RDF assertions to it. I can't > reference it (directly) in a blog. I can't apply an XSLT transformation > to it. I can't incorporate it by reference from another XML document. In > other words, by hiding it behind RPC I've lost all of the advantages of > this World Wide Web we've built. For the most part, REST is just about > *NOT* doing that. Keep things in the one, global namespace that we > share. Don't invent new, proprietary namespaces like "getArticles" and > "getStockQuotes". That's why REST requires no new technologies. It is > about NOT applying "LAN habits" to the Internet. > > Now in Python I can convert the URI to a DOM like so: > > url = "http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer" > data = urllib.urlopen(url) > dom = minidom.parse(data) > > If the data used a well-known serialization format like XML-RPC's or > MIME-RPC's or the SOAP Encoding then I would deserialize it directly > instead of using a DOM, and it would be essentially as easy to use as > XML-RPC: > > url = "http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer" > data = xmlrpcdecode(urllib.urlopen(url)) > > If you're interested, we can work together on REST-ifying the Manila API > or any other API of your choice. I'll do most of the work, you just have > to help me interpret the original API. When we're done, you can compare > the costs and benefits of the two APIs. You can decide whether or not to > implement the REST version in Frontier based on those costs and > benefits. > > Paul Prescod > > ----------------------------------------------------------------- > 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> >
|
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
|