Transitioning From Object-Oriented to Resource-Oriented Programming

Ten years ago I was hired by a fairly sizable corporation to help them transition from procedural to object-oriented software development. At that time, many businesses have been going through the growing pains of adopting object oriented model, which most of them didn't find very palatable.

Fast forward to present time, when we see how most business have made a successful transition to object oriented model of development. But have they made a successful transition to a more productive way of developing software?

Time for a Change (Again!)

Just as everyone is settling into a comfortable groove, there comes another jolt. Unexpected, to be sure, but nevertheless absolutely necessary. We're talking about the resource oriented development.

What is resource oriented development? It's the type of development that adopts one powerful abstraction (i.e. resource) and then enforces it onto any problem area.

This is not the first time that we've been doing this. In Unix world, for example, we had file oriented development. Unix mindset adopted a very powerful abstraction named file, and decided to enforce that abstraction onto any problem that Unix developers might be trying to solve. It proved to be a very powerful way of doing things, as the ongoing success of Unix platform attests to this very day.

Similar thing was happening in other areas with procedure oriented development (also known as procedural development). A central abstraction (i.e. a procedure) was used as a philosopher's stone to be applied to any and every kind of programming problem.

Then object oriented development became the order of the day. This type of development adopted the notion of object. Everything is an object. Thus, enforcing this abstraction onto any problem domain, object oriented development was able to make major inroads in the world of software development.

But today we're finding that objects, as an abstraction, are not cutting the mustard when it comes to challenges of software development. We will explain now why is that.

Objects are an Extensible Protocol

Great thing about objects is that they behave. Unlike files and resources that just passively sit there, object actively behave. That was, and still is, their biggest selling point.

But that's also their biggest shortcoming. By being endowed with the ability to behave, objects have become unpredictable.

If we examine a typical object, such as for example a Customer, we see that it has a public interface. What that means is that we can send messages to it and it will respond to those messages by behaving. In less technical parlance, we usually say that objects are 'bundles of capabilities'.

The collection of these capabilities is what we call a protocol. Protocol exists in order to enable third parties to join the conversation. If a third party does not understand the protocol, or if it isn't even aware that the protocol exists, its attempts to join the conversation will be futile.

So where's the problem? The problem lies in the fact that the object-defined protocol is entirely arbitrary. This means that an innocent bystander (i.e. a third party) stands very little chance of knowing about that arbitrary protocol. It must learn about it, it must somehow discover it.

The very fact that the onus of discovering/learning the protocol is placed on the client (i.e. on the consumer) means that the solution is very expensive. In contrast, any client using the 'file' abstraction in the Unix solution is free from any such expectations. An innocent bystander in the Unix world is only expected to know the standard, immutable protocol (which is by the way quite simple) in order to accomplish anything.

The limitlessly extensible protocol that the world of objects imposes on software developers is very detrimental to achieving elegant, acceptable solutions. Something must change.

Rediscovering the World of Resources

Resources are limitless. So how's that an improvement over the world of objects?

In the resource oriented development, we tamper the infinite and unpredictable variety of resources with the extremely rigid and simple protocol. True, there are possibly countless resources we might encounter, but the way to engage in the conversation is extremely simple and immutable.

Basically, we have adopted the Hypertext Transfer Protocol (HTTP) when dealing with resources. And this protocol defines extremely stringent set of acceptable behavior. In a nutshell, when dealing with resources, we can identify and locate them via the abstraction called Uniform Resource Identifier (URI). Once identified and located, a resource is susceptible to only a handful of possible behaviors. And in practice, this set of acceptable behaviors boils down to four notorious ones:

1. Deliver the representation of the resource
2. Modify the resource
3. Destroy the resource

In addition to the above, it is also possible to add, or create a resource that never existed before.

This protocol is published worldwide, and shouldn't come as a surprise to anyone using the web to accomplish something.

The rigidity and the immutability of this protocol offers a lot of power and robustness to the software written to accommodate it.