Dare Obasanjo: When talking about REST and HTTP-For-APIs, we should be careful not to learn the wrong lessons from how HTTP-For-Browsers is used today
My two cents: you have to look deeper. Otherwise, you will miss the fact that the split is actually elsewhere.
99.44% of the requests your web server processes are for GETs. There are trace amounts of everything else — and a lot of that is spam and can’t be trusted.
Focusing on the trees (whether the trace amounts of other requests are all POST or use the full WebDAV vocabulary) misses a bit of the forest.
The most fundamental constraint is that HTTP is fundamentally request/response, as in one of each. With GET, the request is already spent, and the recipient has very few recourses but to cope with whatever cards it is dealt.
With all other verbs, the available options are wide open. Such processors can afford to be a bit more Draconian. In fact, being liberal with unsafe verbs opens up vectors for exploitation. (Note: this is also true for browsers that take unsafe actions in response to HTTP GETs, hence Ian’s reference to security bugs)
Looking at the emerging APIs, I’m pleased to see that a lot more focus is being placed on the safe/unsafe split.