Andrej Koelewijn

Stefan Tilkov blogged on the recently created SOA manifesto. He’s a big proponent of using REST(ful HTTP) for achieving SOA goals. One of the reactions he got on a previous post on this topic states that REST and SOA are incompatible, as REST is not about services but about resources or documents (with a standardized api).

Personally i don’t care if REST fits the SOA definition or not. My problem with services is that it’s too RPC focussed. It’s all about calling methods on services with interoperable interfaces.

IT is never just about methods or just about documents (or resources, or data, or records, whatever you call them…), you need both. You need data and you need methods. That’s one thing object oriented learned us. But accessing data only by some predefined methods is usually very limiting.

I value methods that are reuseable and technology independent (increases the chance of reuse). I also value easy access of data with the power of a good generic query language like SQL provides.

We need both, and both need to be interoperable, reusable, location independent, and technology independent. Currently the generic data access is mostly handled by copying all the data from the services into one big dataware house, which can be accessed from Business Intelligence tools.

Combining REST with something like Linked Data and Yahoo Query Language (YQL) shows you that you can have expressive data access which is reusable, location independent, and technology independent. Data accessible like generic services. Btw exposing data through rest doesn’t mean you have to expose the data implementation details. Databases have solved this long ago with things like views. There’s no reason why REST resources couldn’t present a view like layer on top of the actual data.

We need both RPC and data. And personally i think that’s it’s probably easier to do both in REST than to do both in RPC, because of the LinkedData nature of REST.