At the risk of being down-voted by the HN-hive mind (this place is seriously getting as bad as reddit)...
There is a subset of developers in the valley who pride themselves on trying to build the perfect REST API. Arguing over things like PUT v. POST, laughing at people who have to use ?_method= hacks to get around corporate firewalls, and trying to pack as many query parameters into the path as possible. Things like this SO thread really get them excited, so its a magnet for upvotes.
The problem is, while technically correct, this is counter-intuitive to how you should be building an API. Unless you are going to be providing fully functional libraries in all the major languages, your number one goal is making it so damn easy your average contract programmer from Accenture (who often don't even know POST exists) could use it. Unless you have a compelling wealth of data hidden behind your API (Google, eBay, Amazon, etc.), or extreme user demand (Flickr, Facebook, etc.), you have to make the bar to entry as absolutely low as possible or you will never get traction.
The problem with many articles about REST is that they revolve around the question how to make your API more RESTful, and rarely answer why (and if) it actually makes sense to do so.
I think that proper use of HTTP methods is one of the core ideas of REST, but I understand that one might have to take shortcuts like _method to satisfy real-life needs while calling it RESTful to satisfy the buzz-word hungry PHB.
Let's just agree not to do something like GET /foo?_method=DELETE
I agree, this post is a typical reddit post. HN should not allow people under a certain karma to post. This would prevent a lot of sh*t to be post. This would also maybe prevent some startups from launching their product on HN just because they know HN will drive a lot of people on their website.
There is a subset of developers in the valley who pride themselves on trying to build the perfect REST API. Arguing over things like PUT v. POST, laughing at people who have to use ?_method= hacks to get around corporate firewalls, and trying to pack as many query parameters into the path as possible. Things like this SO thread really get them excited, so its a magnet for upvotes.
The problem is, while technically correct, this is counter-intuitive to how you should be building an API. Unless you are going to be providing fully functional libraries in all the major languages, your number one goal is making it so damn easy your average contract programmer from Accenture (who often don't even know POST exists) could use it. Unless you have a compelling wealth of data hidden behind your API (Google, eBay, Amazon, etc.), or extreme user demand (Flickr, Facebook, etc.), you have to make the bar to entry as absolutely low as possible or you will never get traction.