[icebraining]

The description of the POST method is very generic; one of its functions detailed in the HTTP spec is:

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

Which fits with much more than mere CRUD. And it's specifically written that it doesn't have to result in the creation of a new URI-addressable resource.

(Also, REST isn't HTTP, you can comply with the former even if you're violating the latter, and vice-versa)

[lmm]

> Also, REST isn't HTTP, you can comply with the former even if you're violating the latter, and vice-versa

Exactly. Complex processing via POSTs instead of distinct URI-addressable resources is HTTP-compliant but not REST-compliant.

[icebraining]

I just don't see how it violates any of the REST constraints.

[mi100hael]

I think of REST imposing a certain grammar that HTTP alone doesn't necessarily require. Remember, REST is resource-driven.

- HTTP verbs are like normal verbs. They represent an action.

- URLs represent the location of a resource or collection of resources.

- Resources are like nouns. They represent what is being acted upon.

As soon as you start assigning different actions based on different URLs, the HTTP verb no longer actually represents an action and the URL no longer points to a resource.

[icebraining]

If you make an analogy, and then the analogy breaks, I'm not sure that shows the flaw is in the original concept.

A RESTful architecture needs an Uniform Interface, yes, but their it's doesn't have to be an "action" or anything specific. POST has a definition, and everyone handling the requests can rely on it. That fulfills the constraint.

[mi100hael]

It's not really an analogy, though. If you have a POST request triggering some random sequence of actions, what's the resource? What representation of state is being transferred?

It's not REST, it's just HTTP.