[
Lists Home |
Date Index |
Thread Index
]
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
|
