I found an article on Luke Francl's blog about one of those esoteric debates between SOAP and REST for web based APIs. It was between a REST fanboy and a fictitious EBay Architect. It is supposed to be a nine part series, but has stalled a month ago on issue #2.
The REST fanboy was schooling a fictitious EBay architect about why the SOAP-based EBay API sucks... it was fairly one-sided, and had multiple errors and omissions.
Suddenly... a real EBay architect decided to challenge the fanboy on his blog. And, in a nice way, dared the REST fanboy to stop shadowboxing, and submit his questions to a real developer who can defend EBay's SOAP-based API.
Nerd fight! Fighting nerds! We don't use guns, we use words!
I read all of the blog posts, and am still fascinated about how people just don't get what an SOA really is... One commenter summed it up nicely:
SOA != SOAP
Back to the original rant... I am generally not a fan of REST for multiple reasons, including:
- It treats file uploads like second hand citizens. If it ain't XML, REST doesn't know what to do with it. SOAP on the other hand, handles multiple file streaming formats nicely.
- It fundamentally breaks its own philosophy about portable URLs by using the same URL for viewing and adding items. It hides the details of what happens in HTTP black magic. No good.
- It continues to cram the antiquated and counterproductive object model at us for network applications. We tried that three times, it doesn't work! Services are the way to go, and SOAP is a natural choice (although neither necessary nor sufficient) for SOA.
In that second item, I'm referring to the difference between REST and frameworks like Ruby On Rails and Django. In a Rails/Django application, if you enter the URL http://host/customer/, you will see a list of customer entries. If you change the URL to http://host/customer/add/, it will usually show you a web form where you can add new customer entries... although you can modify that if you want.
Clean. Simple. Extensible. Logical. You can easily map that URI to a SOAP service name and call it a day (but nobody does).
However, in REST you are supposed to use the URL http://host/customer/ for both the display of a customer, and for modification. The magic is that a HTTP GET method will return the list, whereas a HTTP POST method will allow modification.
News flash to REST fanboys: there are probably more than two things that you would like to do with a customer besides viewing and modifying... what if you want their purchase history? How about a contact form? How about a list of customers who canceled their subscription? You need something extensible; something that can break rigid standards in favor of solving business problems.
Sure, you can cram that flexibility into REST, but then what's the point of the entire REST analogy? We are always hearing about how the HTTP methods POST, GET, PUT, and DELETE map so nicely to the Create, Read, Update, and Delete database model. If you abandon that, what else is left?
Another news flash: a web application should be more than a database front-end. If I'm wrong, we can scrap every web app in the world and just use phpMyAdmin.
Plus, all of that talk about SOAP not being scalable is just plain marketing FUD. There are a billion ways to make web applications faster and more scalable, and it usually involves some kind of federation, combined with caching.
Thanks for reading... I had to get that off my chest.