[
Lists Home |
Date Index |
Thread Index
]
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@prescod.net>
To: <xml-dev@lists.xml.org>
Sent: Sunday, February 17, 2002 2:11 PM
Subject: Re: [xml-dev] 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>
>
|
