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