So, here is what I do not like in the REST Hype that is around.

• despite it is “de facto” the way the Web works, REST is counter-intuitive to me.
  It is counter-intuitive because since when I first started to program, I was told to use “subprograms”.
  And, when I moved to Object Orientation, I was told to invoke methods on objects.
  In summary: if we need to use an “addressing space” that is as wide as the whole Internet (and, not simply constrained by the virtual memory given to my executable), I do not see why I should change the way in which I am programming…why should I avoid the “invocation” paradigm ?
• I think that REST does not add anything on the top on SOAP (or its XML-RCP ancestor).
  It is isomorphic to SOAP. Just using “nouns” instead of “verbs” simply shifts the complexity from one part to the other…. with the side effect of making the things less clear (at least for me, as I am used to add meaning to the verbs I use to describe “actions”)
• I think that REST assumes that the world is painted with one color only: stateless.
  The reality is seldomly “stateless“.
  A lot of times, it is “stateful”. And, maybe I am wrong, but I think that it is better to consider “stateless” as a subcase of “stateful” than the viceversa.
  Statelessness is great for scalability; of course! The Web is so scalable because it is stateless; sure! But, here we are not talking about pages, we are talking about an “addressing space as wide as the whole internet“. We are talking about applications that use such a big space.
  I understand that the use of REST makes it possible the different caching levels the internet provides; but in so many cases, the data that are manipulated by internet-wide applications are changing so frequently that caching is not an option.
• With REST, the “state transition” is in the protocol. I am used to manage the “state transitions” in my code.
• I fear that REST brings back two-tiers architecture.
  Issuing GET, POST, PUT and DELETE operations on remote resources looks, to me, very much like performing CRUD operations on a remote database: something we have learned not to do.
  I understand that the implementation of a REST service makes sure I am not actually accessing the physical row in a database… but this is true for any RDBMS, actually.

I realize that an important part of the hype on REST is due to the fact that SOAP is so complex!

And I agree that REST is, certainly, a great way to address resources; it is really great when you can easily put an URL into some code and create those cool mashups!
But I would not like to extrapolate that, since something is so easy to use, then it is the only way (or the correct way) to accomplish a given task.

As I said, these are just few thoughts that I have in mind on this subject. I know that there will be arguments to address each of those concerns and to take me back on the “right way of thinking“….

P.S. : By the way; few of the previous thoughts would also apply in favor of an RPC approach to WebServices!