SOAP, REST, EBay, and Fanboys

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:

  1. 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.
  2. 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.
  3. 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.

comments

Get informed

Bex, I think you should inform yourself a bit more on what REST is. REST is not just XML over HTTP. See Luke's own set of links, as well as articles by Mark Pilgrim or Sam Ruby.

Ah the old Serious Business Stuff argument. What about REST is not extensible? What about

Also, I invite you to rebuke some of the points against SOAP made by Pete Lacey in his recent InfoQ interview.

Cheers,
/Nick

thanks for the links

I've read a few of those previously... I'll see if the others change my perceptions.

Your point about REST being extensible is correct, as I mentioned in the article... but then aren't you breaking some of the REST 'rules' about using GET, PUT, POST, and DELETE?

As I said, if you break that rule, then you allow multiple URLs to describe the namespace to 'insert a new customer entry'. Well, then... how can you make the argument that a REST based URL is in any way more intuitive or better than verbose SOAP service names? Sure, you no longer need ugly WSDLs, but what replacement for REST has the same toolkit support as WSDLs?

After you remove that, what's left? A philosophy, not a technology, IMHO... and it can be easily ported to SOAP.

If the goal is to simplify SOAP, then simplify SOAP. I hate RPC with SOAP, and most of the WS- stack, but pure SOAP is still pretty slick. I have yet to see why people love REST so dang much when they can just clean the cruft off of SOAP, and follow the GET rules for SOAP that REST does.

read the InfoQ interview

OK, I read the InfoQ article, and I can't say I disagree with him. But his article was NOT about the merits of REST, but about the cruft of SOAP. He's arguing against bloated SOAP frameworks, not SOAP itself.

To be clear, most of the work I do with SOAP used skips Schema, WSDLs, and data binding entirely. Those are complicated, slow, and tightly coupled: the exact opposite of what a good SOA should be. A lot of the Stellent Content Server uses the "loose and fast" approach with custom validation. I talk about this at length in chapter 2 of my book.

Since XML and HTTP are built into most languages, there is little need for SOAP frameworks at all. I make SOAP envelopes from scratch, and POST them with standard HTTP methods. Or I'd use a HTTP GET with a Content Server URL, and slap on "&IsSoap=1" as a parameter. This will return things like search results as SOAP formatted text, instead of a HTML page. In either case, I use XPath to parse the results. Loosely coupled, and nothing magic.

A couple hundred lines of code, and you can execute a SOAP request from anywhere without any toolkits: Java, JavaScript, VBScript macro running in Excel... you name it. Then you can re-use your mini-framework with ease.

I never put much faith in WSDLs and data binding... because from a security standpoint you should never trust data sent to you over the network. Just because the WSDL toolkit validated that the parameter is a string, that doesn't mean the string is free of SQL injection attacks!

breaking rules

rest doesn't mean you use one url for everything. anything that reads, use GET, anything that modifies/updates use POST, creation PUT and deletion DELETE.

if you only do these 4 things with one data type, then one url is all you need, but as you point out - that's rarely the case

John.

hello

Very good informations , thanks...evden eve nakliyat

Recent comments