Why REST is BEST articles
by Jim Alateras
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.
I became aware of the acronym REST from O'Reilly weblogs about three years ago, and was pleased to find a name for something I'd been doing since my first open source outing. I exploited characteristics of the protocols I was using to define a simple grammar for URIs, whereby you could get automatic responses in various formats from hyperlinks. I've changed a lot of things since then, but this aspect of my systems has only been leveraged more because it's simple, intuitive, and powerful. I honestly don't understand why there's still considered any controversy, and hope you'll all move on soon.
well the point of interoperability in the comparison between Rest and SOAP is that Rest has it, and SOAP promises it, and promises it, promises it a bit more. I've been getting promised SOAP interoperability since 1999, and in that time the target has moved further and further away.