REST Questions

Paul Prescod paulp@ActiveState.com
Sat, 25 Aug 2001 18:23:18 -0700


Dave Winer wrote:
> 
> I don't understand why this is better. Scripting languages 
> have constructs for navigating data. 

Scripting languages (or programming languages in general) aren't the
entire universe. There are all sorts of declarative contexts where a
scripting language is extra needless glue. I am one of the world's most
rabid scripting language advocates but I still think that we need to
reduce the requirement for glue in the universe as much as possible.

There are also all of these other "dumb" generic URL-handling tools like
browsers, bookmark managers, XSLT transforms, caches, spiders, robots,
search engines (structured and full-text), loggers, redirectors,
proxies, annotators (oh yeah, you don't like those!), connection
visualizers, site mappers, stylesheet engines, report generators and
command line download tools (like lynx -dump or wget) ...

Those all work on URLs and most don't work with the results of
function/method calls. When you use URLs you get network effects that
you don't get out of function/method calls. Here's an XSLT script that
prints out the categories that Google assigns to you:

<?xml version="1.0"?>
<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:version="1.0">
    <ul>
     <xsl:for-each
select="document('http://www.google.com/xml?q=Winer')//CAT/GN">
         <li>
         <xsl:value-of select="."/>
         </li>
     </xsl:for-each>
     </ul>
</html>

I could do that in a scripting language also...but the fact that
Google's XML service is URL-based means I can choose to use a simpler
tool. (XSLT is totally non-object oriented and for generating HTML from
XML it is very powerful).

Yes, any one tool could be taught about function/method calls but the
cumulative cost about teaching all of them is massive and in the end you
stil don't have as powerful a system as one where everything lives in a
single URL namespace.

Consider if Excel 2003 had an "evaluate URL" instruction. I could
combine structured numeric data from two sites in a function like this:

formula( url("http://www.google.com/xml?q=Winer#//M") -             
url("http://www.google.com/xml?q=Prescod#//M"))

I know nothing about Excel formulas so that syntax is bogus. (it turns
out that Winer occurs on the Web much more than Prescod!)

> ... It seems a waste to go 
> to string constants so quickly, how do you iterate over all 
> the items in "mymachine" -- and why would I want
> to use URLs for that. Dave

If the URL "http://mymachine" returned XML then you could iterate over
the elements. If your language "recognizes" the namespace that the XML
uses then it could load a custom handler that provided object oriented
access to it. Providing object oriented access to things that are
otherwise passed around in strings is not difficult. That's what the DOM
does. That's what Python's "mime" module does. That's what Python's
"zipfile" module does.

So in my vision, FrontierScript or Python would recognize when they are
being asked to download XML in a special namespace and construct the
right OO abstraction on the client side. Perhaps something like WSDL
would allow these OO abstractions to be defined in a
language-independent manner.

Insofar as SOAP has no concept of "references", the model I outline
could actually do a better job of simulating OO than existing SOAP
libraries do.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook