The problem is that with the REST standard there are a lot of edge cases that are not commonly used. REST advocates cannot claim that no one is using REST "prop

The problem is that with the REST standard there are a lot of edge cases that are not commonly used. REST advocates cannot claim that no one is using REST "properly" and at the same time say that REST should be used because it is so common. Take the Dropbox debate, one prominent post featured on HN said that they should use a PATCH request type, which is very rarely used (outside I think certain version control systems). I imagine plenty of developers who want to use Dropbox's API have not heard of a PATCH request type. So yes informal sloppy REST is commonly used and there is some virtue in that, but as any REST advocate will attest to, sloppy informal REST has its drawbacks, as Dropbox found out. Moving to a more formal REST architecture may solve those problems, but you lose the "commonly-used" virtue. Add to that the problem that when you have application logic that is not REST-like, forcing it into REST can require a convoluted middle-layer. Avoiding that complication is worth well more than "commonly-used" I like REST in general, and I even think formal REST with its many HTTP verbs and HTTP headers has a formal elegance. But there are plenty of reasons to go in a different direction, if your application logic favors a different way.