This morning I read Objects at REST written by Rick Jelliffe. It’s an article about how object-oriented concepts can be mapped to REST.

I don’t agree. The similarities between REST and object-oriented software are far less than their differences. REST is set of design principles that decouple software systems in a flexible and scalable manner.

First, REST is about resource representations and stateless protocols. In order to achieve stateless protocols at the object level, all engineers would need to stop using interfaces as they are designed today or rely on something like Software Transacted Memory (STM), which is heavy and doesn’t solve all the inherent problems.

Second, pretty URIs are not relevant. It’s something for humans to enjoy. If you have them, great. If not, it’s irrelevant. Sub-structure relationships are discovered by interaction and never constructed unless told so by the source representation (through a form or code-on-demand). This insulates the client from hard-coded information about the server’s topology. Something, the client shouldn’t know anything about anyway.

Third, not all objects are equal. The first wave of object-oriented programming was about class inheritance. The second wave was about matching interfaces at the instance level only (prototype inheritance). Notice how both have to do with generalizations, not instances. REST cares about the instances and not the mechanism used to create them. You can use structured programming or object-oriented programming to implement your web-services and web-applications. Again, the methodology is not relevant, only the properties of the running system are.

Lastly, and most importantly, is the guaranteed decoupling of the resource’s state from its representation. This means that you have made the major leap already where the consumer’s view of the world is decoupled from the producer’s view of the world. And certainly, this is where REST has made it’s mark. This is how the web works and why it works! In object-oriented design, programmers fundamentally think about sharing objects. This is relevant, because it ties back into the first point. Avoiding state entanglement in object-oriented systems is hard because of the high degree of interconnectedness of objects. In REST, on the other hand, everything is decoupled since the bits are never directly manipulated, only their representations. Hence, this problem is avoided altogether. This is important, because it’s a hard problem to solve after the fact.

In short, mapping concepts from object-oriented programming to REST will make people think about it in the wrong way and therefore do more harm than good.

MindTouch Dream is designed from the ground up to enable developers to build their applications and services in a RESTful manner. We recently put a technology page on our main website that explains the architecture and its motivation.

Beyond web-architecture, I’m also a believer that the REST architectural style will enable us to build better software for multi-core machines. REST web-services already have the properties that are desirable by high-performance CPUs: safe out-of-order execution (stateless protocol), no shared memory (message based), and uniform addressability (URIs).

Lots to think about, just don’t think about objects when you do so!