[bad_user]

I understand why that isn't RESTfull, but why is it more complex?

"customers" are used to thinking in terms of actions. You hit this little button here for payment, you hit this other little button here for shipment. And for developers, these are like methods containing business logic belonging to an object.

So where's the problem?

[pfraze]

HTTP requests are actions -- that's why they have verbs. URIs should be concepts those verbs act upon.

GET /orders/42/pay is a verb on a verb. Maybe not complex, but definitely confusing.

[T-hawk]

PAY /orders/42

That's the most natural mapping, the verb PAY on the object of order 42. Maybe HTTP needs arbitrary verbs instead of a limited predefined set? We'd have to get firewalls and proxies and such out of the habit of processing a request depending on its verb.

[lloeki]

The point of having limited and well defined HTTP verbs means that you know what to expect. e.g GET has no effect on the resource, while PUT is idempotent, and POST is neither. This precise set of definitions, along with the remainder of REST principles mean that friction is greatly reduced when building/consuming APIs.

[pfraze]

There's actually nothing stopping you from using your own verbs, actually; it's allowed. Lloeki gives a good reason not to, though: I don't know how PAY will be handled without consulting documentation.

[bluesnowmonkey]

The HTTP spec is -- it only specifies certain verbs. An implementation need not (and often doesn't) support others.

[scoot]

Isn't how any of the supported HTTP verbs is handled dependant on the API? <consults documentation...>

[pfraze]

Yeah, but not totally. For instance, you can always guess what a GET does. There are properties of the established verbs that you can expect.

[strictfp]

It's not a problem, but you don't get all the benefits of HTTP if you don't respect REST. This since HTTP is built around the idea of REST.

To me it seems logical to embrace the ideas of the tool you are using. If you are not utilizing the power of HTTP, why not just use a pure RPC protocol?

I think that we eventually have to open up for more protocols if the web continues to develop into a generic dev platform. In a sense we are already heading in that direction with WebSockets. But since HTTP has been and continues to be such a success, I think that we can atleast try to promote it.

[kevinpfab]

This configuration can still be RESTful as long as you POST to those endpoints. The complexity I was referring to is the snowball effect of adding different actions.

If you use hypertext in the resources to specify the places the client can go, the complexity is severely reduced. However, properly enabling discovery is where most "Rest" APIs fail.