"The conspicous absence of constraints in SOAP, particularly those that support interoperability is a clear indication of the vacuous nature of the specification." - Carlos Perez
Read the rest in Why REST is Better - Part 4 - Avoiding the Death March.
This is the key problem with SOAP. You can do *anything* with it. Any form of distributed computing you like!
A charitable view would be that it encompasses all philosophies and is better for it. A non-charitable view would be that SOAP is still running around, trying to find out what it itself really is, and has changed its philosophy, radically, at least twice.
When looking at the core ideas that make up REST and asynch messaging, it is absolutely true that you could do all of them in SOAP. But so what? You can do *anything* in SOAP. That is either a great strength or a great weakness, depending on your point of view.
I think it is the latter. Distributed computing is not a problem where Turing Completeness is a compelling argument. This is hard stuff. The network cannot be abstracted away. The only way the world is going to get away from integration hairballs is by latching onto real patterns of distributed computing, not uber-abstractions.
I think those patterns need to be centered around asynchronous, reliable exchange of self-descriptive Unicode messages, between resources that have unique names and standard interactions modelled on speech acts. In short, XML + Reliable HTTP + REST.
[1] http://www.dehora.net/doc/httplr/draft-httplr-00.html
No comments:
Post a Comment