This discussion on whether verbs should be used in URIs is excellent!
Thanks Joe for raising this issue.  It has certainly stimulated new
ideas and questions in my mind.  Let's not let this discussion stop
until we have fully explored all facets of this issue and have arrived
at consensus.  I think that it is important that we (the REST community)
speak with a unified voice.

Let me try to first summarize the issue and both sides of the argument.
Then I will add my own thoughts on the topic.

The issue is this: should a URL be allowed to have verbs in it?

Example.  Here's an example of a URL that contains a verb (add-to-cart)

     http://www.parts-depot.com/parts/00345/add-to-cart

Let's now summarize both sides of this issue

The Nouns-Only Camp

This side of the argument says that URLs should only contain nouns.
They say that verbs should not be allowed in URLs.  Here's why:

1. By definition, resources are "things" not "actions".  URLs identify
resources, not functions.

2. Separation of concerns: keep the identification (i.e., the URL) of a
resource separate from the methods (HTTP GET, POST, PUT, DELETE) applied
to the resource.  In OO terms we might think of the URL as providing the
name of the Object, and the HTTP methods as the generic set of methods
on the Object.  For example:

      {http://www.parts-depot.com/parts/00345}.GET()

3. Generic interface: keep the interface to resources generic - the HTTP
methods.  When you allow verbs then you are essentially expanding the
interface.  For example:

    http://www.parts-depot.com/parts/00345/add-to-cart

is essentially a composition of methods:

      {{http://www.parts-depot.com/parts/00345}.add-to-cart()}.GET()

Thus, the resource (part 00345) is exposing an implementation function,
add-to-cart.

The Verbs-Allowed Camp

This side of the argument says that URLs should be allowed to contain
verbs as well as nouns.  Here's why:

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"

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

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.

Is this a fair summary of both sides?  If not, please add/correct.

Now for my own comments:

As always, I think best with a concrete example in front of me.  So,
let's consider Parts Depot.  This company has deployed some Web services
to enable clients to:

1. Get a list of parts
2. Get detailed information about a part
3. Purchase parts

It is the third service (purchase parts) which is most relevant to this
discussion.

Let's suppose that the client has used the first service to get the
parts list, and then used the second service to drill down to get
detailed information about part 00345.  Suppose that this is the
response:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
         xmlns:xlink="http://www.w3.org/1999/xlink">
       <Part-ID>00345</Part-ID>
       <Name>Widget-A</Name>
       <Description>
           This part is used within the frap assembly
       </Description>
       <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
       <UnitCost currency="USD">0.10</UnitCost>
       <Quantity>10</Quantity>
</p:Part>

Suppose that the client decides that he/she wants to "add this to
his/her shopping cart".  To provide this capability Parts Depot may
provide another element <AddToCart> when it returns detailed part
information.  Thus, instead of the above XML document the client would
receive this:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
         xmlns:xlink="http://www.w3.org/1999/xlink">
       <Part-ID>00345</Part-ID>
       <Name>Widget-A</Name>
       <Description>
           This part is used within the frap assembly
       </Description>
       <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
       <UnitCost currency="USD">0.10</UnitCost>
       <Quantity>10</Quantity>
       <AddToCart href="http://parts-depot.com/parts/00345/add-to-cart"/>
</p:Part>

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 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.

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