Why REST is BEST articles

by Jim Alateras

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.


2005-03-31 09:52:56
RESTing easy
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.

But since I'm always doing my own thing, I'm not considered part of these conversations so, as usual, who cares what I think? I've been committed to thoroughly original software work, but that appears to go against the grain of the O'Reilly community's penchant for buzzwords, acronyms, vendor paradigms, and fad development tools. I was recently notified that my proposal for OSCON was rejected, which is fine; it's the conference organizers' prerogative to determine what's useful and interesting. Unfortunately, the truth is I can see in my log files that nobody even looked at what I proposed. Well it's sad to report that narcissism, NIH syndrome, and lazy imaginations appear to have beaten this Artur Clennam out, but I'm not going to lose any sleep over it. I know the value of what I'm working on and I've got better things to do, so I'm off.

Enjoy your world. Sorry I couldn't contribute.

2005-04-03 10:34:37
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.