SOAP vs REST
I was reading an article about SOAP vs REST earlier tonight. The article has O’Reilly and Amazon both weigh in on SOAP vs REST and, predictably, SOAP gets smacked around quite a bit:
I think there are also some political aspects. Early in the web services discussion, I remember talking with Andrew Layman, one of the SOAP architects at Microsoft. He let slip that it was actually a Microsoft objective to make the standard sufficiently complex that only the tools would read and write this stuff, and not humans. So that was a strategy tax that was imposed by the big companies on some of this technology, where they made it more complicated than it needed to be so they could sell tools.
I’d say that’s a pretty fair assessment of SOAP. You could do it by hand (I know people who do), but at the end of the day you’ll just end up hating your life. You really need tools to help you out if you’re going to seriously party with SOAP. Honestly, for most applications I think SOAP is overkill. You won’t need 90% of what SOAP provides you and in the end you’ll still pay full price for using it. I’m sure somewhere, someone needs all that complexity…but the odds are pretty good you’re not that someone.
REST is touted as the simpler alternative. Unfortunately, depending on who you’re dealing with, REST isn’t always easy. If you’re dealing with REST fanatics, they’ll pick you apart on your use of HTTP telling you that you’re not doing “pure REST”. The problem is, REST means different things to different people because it’s loosely defined (that’s intentional). But because it is loosely defined, you’ll be hand rolling much of the code need to get the job done.
Personally, I don’t care one way or the other. Make it easy for me to develop against your stuff and I’m much more likely to use it. If I have to spend a bunch of time getting up to speed, I’m going to get bored and lose interest. It won’t matter if your service provides the neatest stuff in the world, if I swear uncontrollably and rip out my hair trying to use your service, you’ve failed.
May 5th, 2006 at 8:46 am
Loosely defined? Yikes. REST is as rigorously defined as I’ve known any technical term to be.
See for yourself;
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
May 5th, 2006 at 11:38 am
Okay, maybe defined is the wrong word. It’s loosely spec’d, especially when compared to something as verbose as SOAP. For instance, REST doesn’t specify the encoding of the request or the response. SOAP does.
May 5th, 2006 at 12:53 pm
Ah, I see what you mean (and somewhat disagree, but nevermind). But it isn’t REST which doesn’t do that, it’s just the set of existing specs used on the Web, like HTTP.
May 11th, 2006 at 2:18 pm
I am here to say that the “pure REST” argument sets my teeth on edge even worse than the “the only true web services are SOAP” argument did back in 1999.
If somebody would just implement a meaningful “pure REST” service and then demonstrate to me that it is either easier for developer to adopt or provides some other material benefit, then maybe I could be convinced.
May 11th, 2006 at 3:58 pm
Amen brother.