REST makes the OO purist mistake

Reading a post about Thinking about REST I suddenly realised one of the things that I didn't like about REST's view of the world, its the concepts that resources can always "do" things on their own. This is one of the big challenges that people tend to come across when doing object modelling and I really hope that REST isn't (in the traditional way of IT) revisiting the errors of previous generations.

The line that brought it home to me was

5. Services are seldom resources. In a REST design, a "stock quote service" is not very interesting. In a REST design you would instead have a "stock" resources and a service would just be an index of stock resources.

Now the point here is that the idea is that the "stock" resources are able in themselves to perform the required actions of their consumers.

First stage is to take a step back to explain what I mean by the object purist mistake.

The scenario is this, you are modelling a Payroll system and you "know" that objects contain both the behaviour and data for everything in the enterprise, everything that isn't an object is just about looking for objects, all functionality and business logic must be implemented in an object. This then leads to an "Employee" object which contains the method "pay" which enables that employee to be paid, the payroll process therefore just loops through all the employees hitting the "pay" method and all is fine.

The problem is that this isn't how a payroll system works from a business perspective and it certainly isn't how Employees work in the real world (imagine if you could pay yourself, whenever you wanted, and were in control of the amount to be paid). The point here is that certain pieces of business logic work at a higher level of abstraction than objects and you need something else to co-ordinate those elements and apply the business rules that are specific to the business rather than the employee.

The REST example above is making the same mistake, but using an even more obvious example to prove it. Think about a piece of "stock" sitting in a warehouse, even if we say its "smart stock" and its got a sensor tag and an RF-ID tag on it there really isn't much that a box can actually do. You can ask it questions like "what are you" but its not actually possible for a piece of stock to be ordered, it can't pick it self up, it can't write a shipment note and it can't drive a van.

Asking a piece of stock to order itself doesn't make sense in the real world and modelling something in a "pure" way in the virtual world that doesn't represent how businesses actually work is not a great idea.

Now what could work is exactly the same as what worked with Objects, namely that you have a service providing discovery, co-ordination and higher level business logic capabilities with the resources providing that information which is relevant to the specific entity. Limiting Services to just discovery and trying to shoe-horn logic into a resource that doesn't belong there is liable to lead to a system that is unable to match the changes of the real world specifically because it doesn't model how the real world works.

"Pure" models don't work, its why lots of economics is bunk as it assumes that people don't exist and then the theory holds, IT must not fall into the same comfortable trap of beholding a system as conceptually elegant when logically and physically its a bust.

Technorati Tags: SOA, REST, Service Architecture