I have recently read a series of articles on the Manageability Blog titled Why REST is BETTER. This is a short summary of the articles along with my perspective. The articles are definitely worth a read.
The first article makes a case for a uniform, domain independent object interface comprising of CRUD style functionality. I don’t really understand the comparison of SOAP vs REST as the former denotes a transport protocol and the later is an architectural style. Maybe the comparison should be REST and WSDL/SOAP web services. The article also mentions a number of useful principles, which facilitate extensibility, maintainability and coupling, namely coarse-grained method invocation, argument sequencing and interface uniformity.
The second article doesn’t really add much to the why REST argument. It does iterate that interoperability is a key selection criteria for using either and even goes on to say that the interface and it’s uniformity is key to achieving interoperability. No arguments from me on this point although I am not convinced that we need to adopt such a grand unifying theory on interfaces and interoperability.
The third article discusses asynchronous messaging in its two styles, push and pull. In a push based system it is the producer that is pushing messages to the consumer whereas in a pull based system it is the consumer that is pulling messages from the producer. The article argues that the former is more tolerant to interoperability across change and compares RSS with SMTP, the former being pull-based and that later push-based. At the surface the argument seems compelling enough but a deeper level I am not convinced that the benefits are all that clear. The article also touches on pi-calculus and Robin Miner in order to support the significance of URI’s as first class citizens in architectural and design descriptions. The arguments may not be conclusive but they do provoke further discussion.
The fourth article in the series touches on the properties of software architecture (as described by Roy Fielding), the proliferation of WS-* specifications and virtues of aspect-oriented programming. but for me it didn’t add much to the Why Rest is Better argument.
I am currently involved in a mid-sized project, which uses both REST and WSDL/SOAP style architectures. We have recently completed the first iteration and from a practical sense I find the simplicity of REST a very compelling argument to support its use….but the proof will be in the deployment, scalability and maintenance of the service.