The REST zealotry needs to end.
First, let me establish my bonafides here. I work on the ROME project. I built the first module for Google Base. I have used the Propono project to build an APP service. I use REST. REST is a friend of mine.
Here is the thing:
People need to own up to the fact that SOAP has its place. Yes, “SOAP” is neither “Simple,” nor arguably about “Object Access,” and marginally a “Protocol.” But SOAP and WS-* have their place. Just own up to it.
One of the things I had a chat about at JavaOne last year, over a number of free drinks, is that one of the big advantages of SOAP over REST was the use of nillable. There is a complete semantic difference between
So here is my point, REST people… Yeah, SOAP isn’t simple, but the complexity of the envelope tag gives you a clear point to encrypt or pass transaction information. The soap:nillable namespace has to be there, but it doesn’t require a protocolchange. Can’t we just admit that, on a 60/40 basis REST rules? If you want simple and easy and your data conforms to basic preserved ENTITIES, REST is great. When you need encryption beyond basic SSL, differential updates, two phase commits, reliable messaging — all that “other stuff” — WS-* has a place?
I am getting really tired of religious arguments in my space lately. Sure, dynamically typed languages have a place, but static typing has some real advantages. Yes, environment X gives you A, but environment Y gives you B. I am not going to tell anyone that WS-* is the end all be all, but I wish the REST crowd would own up to the idea that WS-* solves some hard problems, and with basic tooling is not “hard to use.”
1. I'd argue that WS-Addresssing is a protocol change, as while the envelope is unchanged, how you talk to things has -you need to include the address, you ought to understand the policy, and your back end needs to dispatch based on the address.
2. the same envelope complexity also introduces lots of ambiguity. WS-A 1.0 does say 'only one WSA header set in our namespace', but ignores the question of what if I also send conflicting headers in three of the draft namespaces in widespread use. Its up to each stack how they handle that.
3. There's a really good defcon paper on WS-Security, which shows that it includes lots of potential attack points.
-steve
"When you need encryption beyond basic SSL"
But how often does that really occur? Remember, we frequently pass our most valuable info (credit card, ssn, address, age) over SSL. And I disagree that it's not "hard to use". It's hard for me.
What difference does it make to 'rest' of the world?
> ENTITIES, REST is great. When you need encryption beyond basic SSL, differential updates, two
> phase commits, reliable messaging — all that “other stuff” — WS-* has a place?
You mean to say to the web does not support two phase commits and reliable messaging?
"When you need encryption beyond basic SSL"
But how often does that really occur?
Almost NEVER! This is my point about James Clark talking about complex signing/encryption strategies on top of REST is that if you need that, step up to "OK it isn't 'Simple' SOAP."
:)
3. There's a really good defcon paper on WS-Security, which shows that it includes lots of potential attack points.
Let's just own up to the fact that "lots of potential attack points" applies to almost any web service. The fact is, in the real world, once you pwn DNS, you pwn.
I'd encourage you to re-read (I'm sure you've come across it before) Richard Gabriel's talk "The Rise of 'Worse is Better'". As far as I'm concerned, REST has better survival characteristics than SOAP.
I recently attended a talk where the presenter compared the 700+ pages you have to grok to do SOAP right with the one page that gets you into REST. The world we live in is one of cost-cutting, lowest-priced providers, outsourcing, and off-shoring. Management wants capability *NOW*; and for *CHEAP*.
On cost and simplicity, REST is going to give SOAP a shellacking.
BTW, I'm not a zealot. Just an ordinary guy with a stay-at-home wife, who wants to continue winning bread in an H-1B world.
Just took a look at the Google OpenSocial API. Looks RESTful.
I know this has the feel of "10 billion flies", etc. Still, you know, Google.
SOAP is just bloated!
At last, someone stating that software engineering is not a black-and-white business. While I admire REST's simplicity and ideas, sometimes you just need to jump through too many mental loops to squeeze everything into the HTTP methods (partial updates being a nice example).
A good engineer should know both alternatives and choose according to the problem/budget/tools etc. After that you just abstract over the entire thing and it doesn't really matter.
Seriously, people, give it a rest ;-)