SOAP stands for Simple Object Access Protocol. But there is nothing simple about it. If you don’t believe me, then go read the specification. It’s not surprising the thing got so out of hand – just look at the list of contributors. They all had to ‘add value’ in some way.
Oh dear.
Thank goodness it’s dying.
It’s one of the conundrums of committee based standards development. Everyone contributes and they morph into these bloated monsters.
The skill of a good software designer is as much knowing where to hold back on features as it is to add them. The software products I love the best are the ones where the creators have managed to figure out how to avoid complexity. Sadly committees are not good social mechanisms for holding back on complexity.
Committee based standards like SOAP almost have no hope of becoming anything but complicated.
Fortunately alternatives tend to naturally emerge from where people take something good that already existed and apply it to solving a problem. JSON is a beautiful example of that.
RESTful web services are to SOAP what JSON is to XML.
RESTful web services did not come about from a committee – it was just people observing that they they could easily shunt data around without using anything more than what the basic HTTP protocol offers. They are light weight, simple and efficient.
I was going to give examples of companies like Fogbugz (here’s their API), 37signals (here’s their API) as examples of smart companies showing the beauty of RESTful APIs and contrast them with SugarCRM which is not a product I respect as much (it isn’t simple) which uses SOAP. But then SugarCRM has just released RESTful versions of their web service APIs. Eh – so even the not so swift companies are shifting away from SOAP.
Clear trend eh?
The market always moves towards simpler less complicated solutions.
