[paul]

Well, I guess it depends how you define "FIT". It's possible to shoehorn just about any service into just about any model, but that doesn't make it a good idea. For example, sending email by doing a PUT to some newly created URL is silly. There's a reason that the english language has more than 5 verbs.

[gaika]

Right, closer analogy would be object oriented programming, where some methods are standard (constructor->post, destructor->delete, copy->get, assignment->put) and some are totally type specific. The point of REST is that these type specific methods do not have to pollute your core / transport and can happily reside in your client libraries.

Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.

[paul]

I think perhaps we're talking about a different aspect of REST.

What I find annoying is people objecting to "POST /actions/subscribe" (with the params in the post body) because it's "non-RESTful" -- the url is a verb and REST demands a noun.

[bct]

REST doesn't demand a noun. If they all have the same code backing them, there's no functional difference between:

    POST /actions/subscribe

and

    POST /subscriptions

and

    POST /abcdef1234567890

The shape of a URL has nothing to do with REST. However, if a lot of your URLs contain verbs it suggests that you aren't doing REST. It's a design odor.

[gaika]

What's wrong with creating a subscription object and letting people manipulate it the usual REST way via /subscription/<id>?

That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.