> 1. It seems natural that you would want to identify a resource and tell
> it to take an action. Some examples:
>
> http://www.my-home.org/air-conditioning/on
> http://www.google.com/search?topic="juice-machines"

You've identified two resources - what part tells it to take an action? and
what action does it take?

http://www.my-home.org/air-conditioning/on could test whether the unit was
on or not. It could toggle the power. It could set the power on, lots of
things.

http://www.google.com/search?topic="juice-machines" - what is it you are
searching for within the 'juice-machines' topic? Or does it return
true/false if the topic exists?


>
> 2. Verb-oriented URLs are very program-friendly. For example, a program
> to control devices in my house might look like this:
>
> http://www.my-home.org/connect-to-central-computer
> http://www.my-home.org/air-conditioning/on
> http://www.my-home.org/air-conditioning/adjust-temp?value=68
> http://www.my-home.org/stereo/on
> http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity
What verb is this? It seems more like a 'closure' - binding action and data
into a single opaque 'invokable' object.
It looks more like these URI are reflections of procedural instructions.
They look to be dependent on the correct sequence to operate correctly. Can
you adjust the temp before visiting the 'on' URL? Having sequence dependency
is an issue in networked apps regardless of what paradigm you are taking.

>
For me it is more program friendly to have something like:
home.server = "http://www.my-home.org/";
home.put("air-conditioning/power,"on");
home.put("air-conditioning/temp","68");
home.put("stereo/power","on");
home.put("stereo/current-album","Timeless-Serenity");

If you wanted api based access, it wouldn't be hard to define objects with
named properties where each property maps to a URI. You could then have the
client do something like:
home.airConditioner.power = "on";
home.airConditioner.temp = "68";
home.stereo.power = "on";
home.stereo.album = "Timeless-Serenity";

The benefit would be that you could also query the current values with the
same object/property structures.

I wouldn't do the 'connect-to-central-computer' because I wouldn't trust
that my-home.org would maintain that connection, or that it wouldn't crash,
etc.


> 3. Unilaterally prohibiting functions as URI-accessible makes the Web
> less friendly and useable, as I will need to contort things to get
> around this constraint. Imagine doing the above using just nouns.
I always do - its easy, very simple and powerful.

...

> Note the last element, <AddToCart href="..."/>. The URL in the href
> attribute:
>
> http://parts-depot.com/parts/00345/add-to-cart
>
> clearly contains a verb, add-to-cart.
I thought it clearly contained the verb "parts". Or maybe it was verb 345. I
forget.

>
> I have a couple of thoughts about this design:
>
> 1. If the HTTP method for the above URL is GET then it is violating the
> principle that all GETs should be side-effect free.
>
> 2. One of the principles of REST is that the client should maintain
> his/her own state. The server should not do so. The above approach has
> the server maintaining state about the client.
Yes - it looks like the add-to-cart URI doesn't know which shopping cart to
add that part to. It'd be easier to have the client explicity ask for a
shopping cart and repeatedly add (POST) part references to it. You'd get
into the non-idempotent issue though - if you POST twice, did you really
mean to add two items or was it a transmission problem? It's probably better
to just transfer a complete representation of the clients PO.

>
> Here's an alternative solution. The client creates a Purchase Order
> (PO) which identifies the parts he/she is interested in purchasing.
> When the client finds a part that he/she is interested in, the client
> will add that part number to the PO. When the client is ready he/she
> submits the PO. Some things to note:
>
> 1. The PO represents the "shopping cart".
> 2. The PO is composed on the client side, not the server side.
>
> This second design seems to be more in the spirit of REST.
>
> Those are the two ways that I see for implementing the purchase parts
> Web service. Are there other (better) ways? Any comments? /Roger
The server can maintain the PO and the client can incrementally update this.
Provide a unique identifier for it & things will be fine (other than more
messages being exchanged & idempotency issues).

Having the client accumulate a single PO with multiple line items probably
makes more sense if you can code the client yourself though. Not all
financial systems make it easy to update POs directly.