For the last 10 months or so I have been quite heavily involved in building RESTful server components and I think now is an appropriate time to retrospect on how my own thinking has changed since then.

For the first month or so I really did get this cool new stuff called REST or to put in more succinctly the whole Roy’s Ph.D. thing was not quite palatable leave alone digesting it :)

Sam Ruby’s book certainly helped in getting features of my application delivered in a fairly restful way but the biggest pain was coming to terms with the idea of your components having an Uniform Interface. I had done some XML-RPC and SOAP over the previous year and when compared with it REST seemed very limiting.

The pain is felt more acutely if you are fall into the trap of thinking that your application must do only CRUD and your objects must be devoid of any other behavior. The operation of HTTP’s uniform interface map very well with CRUD operations on your objects but thinking that every object in your system can have only 4 methods on it did make me say “WHAT!!!!!”

Then along came Duncan Cragg (an ex Thoughtworker himself) and I chanced to read his treatise called The RESTful Dialogues. A must read, notwithstanding its terseness, for anyone trying to get some REST. Of all the episodes the one that I found most profound was the discussion on Business Functions. 

As an Object programmer I was trained to think that each object is a special creature and therefore was blessed with special powers that were bestowed only unto him. So like children, every object is special to its creator. And within the creator lies this great primordial urge to expose the powers of this super child to the whole network AS IS.

And to top it all the Object Oriented in me was spoilt beyond measure with luxuries of turning something into a distributed service just at the click of a mouse in my favorite programming language/IDE. So all in all I was finding it very hard to come to terms with the idea of a unified & consistent network interface for all network components.

So much that I kept arguing saying posting to  ”http://localhost:300/something/do_this” and  ”http://localhost:300/something/do_this_also” and so on was  so much easier way to web scale nirvana (a.k.a ProgrammerConvenience pattern) than understand this whole uniform interface thing.

I was trained by virtue of my experience with monolithic systems in always trying to get my objects to “doSomething” instead of “helping them transform!” or help in “making something so”.


This shift is perhaps what Duncan means when he talks about shifting from the Imperative to the Declarative school of thought .


It feels like there is this fundamental thing that you don’t learn either at school or at work even after spending a lot of time. Its about understanding limitations, on your own! You are never taught to see the limitations of choices you make. We justify and we thus let life ebb away, acting in old ways…


Apologies for the detour.Let me get to the point.


The point is a style may fit well for doing domain objects with rich behavior in a local setting. But when we start unconsciously using this style for building distributed systems we have taken for granted, the appropriateness of this style for a hard problem like distribution. By doing this we have in fact not even acknowledged distribution as an existing problem.


True, habits die hard.


Personally for me without this nearly 15 years old work that has such an unassuming title I would not have understood what distribution is all about.
Creating special purpose behavior is one thing but distributing them is another. Don’t mix the two up with annotations.


More later.