Yesterday at university, we had a little talk about the pros and cons of SOAP. Well, not really, but SOAP was mentioned in one of the presentations, and so the professor suggested "The S stands for Simple". As he promised, it really describes the overengineered-ness of SOAP. I'm probably more the kind of REST fanboy, because it uses a widespread protocol (HTTP) and uses many of the features already present in the HTTP protocol without reinventing the wheel. What if a services moves? Do a HTTP redirect! What if there is no such service? 404! Error handling? If the error happened because of the input data, do a 4xx "client error", if not, do a 5xx "server-side error". It's simply following the Kiss principle.
Nobody likes writing wrappers, "creating" interface metadata that has to be parsed again to know how the interface looks. After all, doing sophisticated descriptions of interfaces will not automatically upgrade clients if you decide to revisit your public APIs. On the contrary, you have to re-generate (hopefully not rewrite by hand) the meta description of your API, and the client has to re-parse, re-generate or otherwise process this generalized description to finally redo their client-side code. On the other hand, when a REST-based API changes, you simply update your client-side code to work with the new API (and data structures, if they change too) and don't have to do much code generation and other "bureaucratic" code-generating nonsense.
HTTP already provides most things you expect from web services, and for really simple APIs (like the YouTube API), you can easily do "web service clients" with some http library and XML-parsing code (or not even that, but only JSON or even plaintext). In Python, I've already done this in python-youtube. The libraries I used: urllib2 and minidom from the xml.dom package - both included in the Python Standard Library. It surely is easier maintainable than, for example, with Python Web Services.
What I really want to say is that if you're doing public APIs, why not simply do it with REST instead of SOAP/Web Services (that is, if you're the provider of these services - you probably can't choose when you are interfacing with web services/APIs written by someone else)?
Subscribe to:
Post Comments (Atom)
1 comment:
I'm a REST fan too, as are most of my co-worksers, but we are now working to provide SOAP access to our services.
Why? Because WSDL makes it so easy to create a stub client. "Just push the button". No need to prise apart your request: just call the function (wrapper). No need to parse the response: just look at the returned object. No need to even write the object: WSDL tools create it for you.
Is it efficient? Not particularly. Is it transparent? Not very. Is it small? No. Is it easy to maintain? Not particularly. But: Is it easy to get started? Delightfully.
Post a Comment