Killing Eterna-threads: REST vs. SOAP

I've heard it said that "Any field that still must use the word Science in its name is still more art than science".  I went to school majoring in "Computer Science", as did many of the readers of this blog.  I think most of us get it that it really is as much art as science still.  Evaluating art relies on subjective judgment.  Evaluating science relies on objective judgment.  These judgments are usually made by experts.  I love the origin of the word "Expert", described as "a person wise through experience", because it is absolutely applicable to this discussion.

In software design, especially the design of information systems, there is still no one true way.  Anyone with experience in the "Art" of software design understands this.  There are lots of different ways to do things, and some are better and some are worse, and which one is better often depends upon the environment, use case, and requirements of the situation.

Often when I'm asked a question about "Should I do X or Y?" or "How do I do X?", my first response is "What are you trying to do?"   I'm trying to understand the environment, use case, and requirements that will let me suggest one solution or another based on my expertise.

Just last week I was in a room full of W3C Standards and IT Experts.  These included authors/editors of W3C standards, committee chairs, book authors, et cetera.  The debate over REST and SOAP which we've frankly stopped discussing for a while in Healthcare IT is still going strong over there.  One thing that was truly obvious to the experts in THAT room is that the relevant points in the REST vs. SOAP debate depends upon the environment.  In "the web", REST dominates with loose binding, dynamic, resource-oriented approaches, and ad-hoc mash-ups.  In "the enterprise", SOAP dominates with strong contracts, definable composition approaches, strong security models, and expected and pre-agreed upon behaviors.

I've seen eterna-threads before ... you know, those debates that never die, and never get solved either.  I build rules for them in my e-mail client so that they get appropriately routed.  The challenge here is not one of science.  These debates cannot be addressed in an OSI 7-layer model.  Instead, you have to jump to OSI-layer 8 or 9 (religion/philosophy and politics) to understand them.  The two camps have even been identified as "Cats" and "Dogs".  I'm stuck in the middle.

To give an example, the author of the Web Application Design Language (WADL) was present at the meeting I attended.  He reports how he was resoundingly "spanked" for not understanding the RESTful "philosophy" regarding interface contracts.  Arguably, that author understands RESTful approaches as well as any practitioner of the art.  In fact, what he did was bring in a requirement "outside" the typical environment where RESTful approaches work, and attempted to integrate that requirement into a RESTful framework. Since the REST crowd didn't see that as a requirement of their "typical" environment, they rejected it as being antithetical to the RESTful approach.

Fielding's paper describes REST as an architectural style and demonstrates its appropriateness for the web.  What others are wanting is a demonstration of this particular style's appropriateness for other environments, such as the enterprise.  We would like to see how features of the current "SOAP" style (e.g., contracts, definable composition, pre-agreed upon or well-defined behaviors, and strong security models) could be addressed using a RESTful approach.

One of the outcomes of the meeting was a suggestion to document best practices in RESTful approaches, and to describe how some of these other requirements: Strong contracts, well-defined behaviors, and strong security models can be applied to REST.  As several "RESTful" experts acknowledge, these aren't antithetical to the approach, they simply haven't been well documented and understood by that community.

It is my sincere hope that a document how REST can work in the enterprise environment is produced, and that it might help the rest of us understand.  If it gets done well, perhaps we can put this eterna-thread to REST.