Thoughts around REST

It is quite sometimes that I have in mind to write down this little comment. I know that, in doing this, I am probably going to be ignored or to be blamed.
But, for all my readers, I am doing this exercise with true humble and open spirit; I am sure that many things I write here represent only a part of the truth, perhaps so little a part…. or perhaps no part at all 🙁 My objective is to understand where I am wrong: so, please, accept my apologies in advance. After all, the motto of this blog is to have “opinions”…. not “truths” 😉 !

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!

{ Leave a Reply ? }

  1. assaf

    A good analogy for REST is calling an object, getting back a reference to another object, calling that object, getting back a reference, and so forth.

    A good analogy for SOAP is only ever calling static methods, and passing arguments around to tell the static method which instance you actually ment to call, if you could.

    So I’m confused when you say REST is the counter intuitive one.

  2. Jean-Jacques Dubray


    when will you finally understand something about SOA and BPM? Distributed computing is not about some piece of code having the ability to call some other piece of code. It is not about distributed objects vs static methods. Distributing objects has been tried countless times. That will never work. The problem is the semantics of monolithic synchronous runtimes such as OO. Trying to make a distributed call local is the problem, not the solution. Yet, you and so many other always come back there.

    You need to create a distributed programming model from scratch, independent of the runtime in which some of the components are implemented. You will actually then understand the need for bi-directional interfaces, orchestration languages, forwards versioning and assemblies. Maybe, just maybe the “unit of assembly” may not the “object”, maybe, just maybe, it could be something else? don’t you think we tried enough times? What’s important is to be able to “assemble” software components that were built by different people at different time using different technologies. It does not matter if it is an object, a static method or a service component?


    thank you for having the courage to not be a “follower” of the “good thinkers” of our industry.


  3. Stefano Pogliani

    I am not sure I would go that far.
    What I, on the contrary, think is that our industry lost a great opportunity. The opportunity to develop something different from the HTML/Javascript in order to support the new generation of applications delivered over the web.

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Social Slider
  • RSS
rss Follow on Twitter facebook linkedin