Jim, REST, Resources, and Services

Those who know Jim and me well always wonder how we can possible work together and produce interesting work since we seem to constantly argue and disagree on things… from who’s the uglier of the two (I usually let him win on this one :-), on all things technology related. I really enjoy working with Jim and especially our disagreements because I learn a lot. Of course, at the end we always seem to come up with a common approach, a single answer. Since we started this blogging thing, however, we have been mostly writing things that we had previously agreed on and kept our discussions private. Well, I think this may be the first time that we are going to disagree through our blogs 🙂 Well… at the end it may not seem really as a disagreement but let’s see how it goes…

Jim posted some very interesting thoughts on REST and our “processThis” (post1, post2) (we are still looking for a better name… any suggestions?) approach. I agree with Jim that transport independence is good but he also suggested that the REST architectural style mixes the semantics of SOAP with those of the underlying transport protocols. I personally don’t think that this is the main issue with REST. At least, it’s not the main reason I prefer service-orientation and the focus on the messages over REST. Also, I disagree with Mark Baker who suggests that the transport-dependence is the main reason some of us prefer service-orientation over REST, DCOM, CORBA, etc.

I personally see REST as a resource-oriented architectural style for building distributed applications. I see its simplicity, its focus on document exchanges (or state representations), and its constrained set of operations with uniform semantics (at the architectural level) as very good steps forward from the traditional object-oriented dominated world of distributed computing. However, REST promotes the resource and its state as the fundamental building block. It encourages the idea of having a set of fixed operations, which are derived by the resource URI’s associated specification; only these operations should be used on/with those resources (e.g., HTTP “GET” source-resource-uri or FTP “PUT” destination-resource-uri or even MYPROTOCOL “SAY” source-resource-uri). At the architectural level, the resources are seen as having state, hence the need to transfer it. It’s this focus on resources and their state that I am not fond of. And if one considers the easily breakable interrelationships that can be formed between resources through the inclusion of URIs in their states, the fragility and maintainability of distributed applications may (but not always) become a major headache.

Furthermore, REST promotes the idea of separating the application protocol from the representation of state but does not attempt to hide that state. REST treats transport protocols like HTTP and FTP as application protocols. Yes, I know… one could define a new application protocol, with a new URI, that was different from the existing transport protocols. However, because the focus is on resources and their state, that protocol would still have to look like a transport one. This is because the new protocol will need operations which, at the architectural level, would have transport-related semantics (e.g., “place”, “retrieve”, “put”, “get”, “move”, etc.) for moving state.

In service-orientation there is no such thing as a resource. That doesn’t mean of course that resources don’t exist; they exist, but it’s just they are not modelled explicitly at the architecture. What Jim and I say with the “processThis” approachs is that there is one verb to rule them all :-). We base our architecture on services with each service having the ability to either receive an instruction to process a message or instruct another service to do the same. We then advocate that the structure and contents of the message is important. It’s from the exchange of these messages that we can build scalable, loosely-coupled applications. Of course, these properties are not guaranteed 🙂

In our approach, we don’t separate the messages and the information exchanged from the application protocol. In fact, there is no such thing as an application protocol common to all applications; there are message exchange patterns and the contents of the messages. The semantics of a collection of a message exchange patterns may be referred to as a “protocol” (e.g., WS-Security, WS-TransactionManagement, WS-FlowerShop). State as we know it is not a first-class citizen. It’s there, services operate on it, we know about its existence but we don’t make it part of our architecture.

I may be wrong on all these of course, so I am sure Jim will put in my place. Hey mate… looking forward to your response.