[
Lists Home |
Date Index |
Thread Index
]
Dave:
I asked earlier that if REST is The Web Way and everyone
knows that, why are the Web Service baseline specifications
based on a functional style? As the cannonized defender
of RPC, can you answer that question? So far, we have a
lot of material from Paul et al on the REST position
(no newtonian jokes, please.. :)), but no one has stepped
forward to defend the web service specification approaches
other than to say as you have said, the toolkits are there.
So Why Traditional RPC? Why Web Services per UDDI/WSDL/SOAP?
len
-----Original Message-----
From: Dave Winer [mailto:dave@userland.com]
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>
>
-----------------------------------------------------------------
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>
|
