Why does including an action verb in the URI in a REST implementation violate the protocol?

I'm finding it necessary to understand why including action verbs in the URI violates the REST protocol for URI syntax? When I read the following article, I sense that too many people are making too much noise about verbs, and that they should be making more noise about content types:

RestWiki: Minimum Methods

In a perfect world, client browsers would all support GET, POST, PUT and DELETE for request operations. However, only GET and POST are supported, which means we're stuck trying to identify operations that should be PUT and DELETE by using common action verbs in the URL like view, create, edit, and delete.

How does this violate 开发者_JAVA技巧the spirit of the REST architectural principles, and what is the roadblock you experience by putting something like "delete" into your URL instead of using "deletion"?

The only valid reason for the guidance around URIs is to encourage proper usage of the REST verbs. If a request performs an action that is consistent with the client's expectation as per the HTTP standards then it really does not matter what the url contains.

Naming urls based on nouns makes it natural to create behaviour that is consistent with the intended purpose of GET, PUT, POST and DELETE.

When you put verbs in the URL it can become very confusing because often the http verb will have contradictory behaviour to the one in the URL. REST rules say you must respect the HTTP verb, but usually the url is more descriptive so it can be misleading.

The fact that browsers only support a subset of HTTP verbs is not really relevant because even when you do have full access to all the HTTP verbs, you still need to be able to model other verbs, like print, close, confirm, cancel.

You are absolutely right that people need to focus way more on content types than URL structure when talking about REST implementations.

Making your URLs refer to nouns is not a REST constraint, it is about encouraging people to fall into the pit of success.

REST isn't a protocol, rather a style. As such you are free to do anything that meets your requirements.

HTTP verbs are preferred if possible, as they are part of the HTTP protocol and as such a standard. It also allows you to use existing security and caching layers on a standard web server, without having to write any bespoke middleware.

REST suggests that we should embrace HTTP, and not add layers of abstraction like SOAP, RPC, or CORBA do. Adding additional verbs, or adding them to the URL could be seen as an, albeit lightweight, abstraction.

However as you righly mention these are not consistently supported accross browsers, or some versions of Flash. Therefore it may be necessary to put them in the URL in the real world, if you are accesssing from the client side.

You should look at this carefully though as there may be serious security issues when performing DELETE/PUT over a URL.

I would suggest that the verbs GET POST PUT and DELETE are suitable for virtually any need. You should not need any new verbs or response codes, as these are intended to be generic. Add further information in the request and response data.

Check out this SO article for more info: Understanding REST: Verbs, error codes, and authentication