Here's the secret of REST: it's all about the
information and definitely
not verbs.
The author begins by confusing HTTP with REST. I understand that HTTP is probably the most common protocol for implementing RESTful architectures, but since the author is devoting so much time to trashing REST, they ought to correctly make this distinction. Hence, the complaint that HTTP verbs aren't adequate to express certain problems isn't a critique of REST, it's a critique of HTTP. This problem is present throughout the entire article.
Then, the author complains about the specifications of REST (i.e. "What a scoop in the software world" with respect to the client/server architecture). Not all applications are well-suite to client/server architectures -- those applications are not well-suited for REST. Some principles of any architecture may seem simple, but I don't think that's an inherit problem.
The author really revealed their ignorance with:
>Rest is awesome, because it is STATELESS. Yes there is
>probably a huge database behind the webservice, but it doesn't
>remember the state of the client. Or, well, yes, actually it
>remember its authentication session, its access permissions…
>but it’s stateless, nonetheless.
REST is not stateless, RESTful communication is. This just means that each request from the client contains the information necessary to create an appropriate response -- and that this is possible for all resources. That implies that issuing temporary authentication tokens is
not RESTful, since an initial authentication request is required to create a second "meaningful" request. This is a desirable trait for many classes of applications.
However, all of this being said, the proposition 'REST is sometimes used inappropriately' is true, and it is interesting and constructive to identify situations where REST is being used inappropriately. It isn't clear to me that RPC calls are appropriate in all (or even most) places REST is used.
Rants like the one in this article are really toxic, simply because they make people think this is an acceptable way to approach technological problems. What would actually be useful is to:
* identify and find examples of misuses of REST
* try to create a taxonomy of REST abuses and recommendations for those scenarios