> Why Deviate?
> Although REST prescribes using HTTP GET, PUT, POST, and DELETE verbs for CRUD operations, some clients can’t generate the less common PUT and DELETE requests. In addition, some overzealous firewalls block PUT and POST. Thus, some RESTful APIs accept all requests via HTTP GET and place the HTTP verb in the querystring. For example, to delete user 124, the GET request would be for the following URI: /users/124?method=delete This technique is especially common in Ruby circles. Another benefit of this approach is all requests can be easily generated and manipulated in the address line of any browser.
This is a very bad idea for something like delete. It's Daily WTF material:
Some people resolve this with the X-HTTP-Method-Override header which I believe is a lot more clean. This is very helpful in situations where certain strict REST clients don't support PATCH (the underrated verb to help with partial updates).
Overloading the request method using URL paramaters, as the author mentions is a bad idea. What is accepted behavior, is overloading the request method using hidden form data in a POST request.
"There are two noncontroversial uses for overloaded POST. The first is to simulate HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE" - RESTful Web Services, Leonard Richardson & Sam Ruby.
This I agree with. But that comes a lot closer to honoring the semantics of the HTTP verbs, too. I do understand the need to be flexible sometimes, especially when some things aren't well-supported, but I cringe whenever I see GET requests changing application state.
This is a very bad idea for something like delete. It's Daily WTF material:
http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
Any firewall that blocks POST requests but not GET is a WTF in and of itself, for that matter.