Sat, 25 Aug 2001 17:16:58 -0700
I don't understand why this is better. Scripting languages have constructs
for navigating data. 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
> I'd rather see:
> for msg in msgopen("http://mymachine/inbox/messages")
> if msg.subject contains "REST"
> I use "msgopen" to invoke some client-side code that knows how to read
> the "messages" mailbox format and generate a friendly object. Otherwise
> I could work entirely at the HTTP and XML level but it would be less
> Note how I can treat Clay's mailbox and mine sort of symmetrically. And
> given the password I could read remote mailboxes as easily as local
> ones. Assuming this is all XML, I could easily build indexes of my
> messages using any XML aware tool from XSLT on the low-end to C++ on the
> high end. Hell, I could use "lynx", "sort" and "grep".
> There is a real connectivity and "diminished network effects" cost in
> using non-HTTP protocols (even if the non-HTTP protocol tunnels through
> HTTP). Service creators should have a really good reason to move away
> from the unified model of URIs as the locator mechanism and HTTP as the
> If your goal is to share information (including the results of
> computations and database queries) then RPCs don't really seem to
> simplify anything. After all, what could be simpler than dereferencing a
> URL? Bluntly: stockquotes don't benefit from RPC.
> If your goal is to invoke some remote processing ("reboot yourself",
> "clear your cache") then maybe RPC's implentation simplicity overwhelms
> the benefits of REST that I can see...
> Take a recipe. Leave a recipe.
> Python Cookbook! http://www.ActiveState.com/pythoncookbook