REST Questions

Dave Winer dave@userland.com
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"
>         msg.forwardto("http://shirky.com/~clay/inbox")
>
> 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
> convenient.
>
> 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
> protocol.
>
> 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
>
>
> http://xent.com/mailman/listinfo/fork