I'm over in Barcelona this week for TechEd EMEA Dev Week.  Many thanks to all of you that attended my session on "SOA Governance and Service Virtualization" on Wednesday and asked some great questions.  It is great to get some international perspective to our solutions and approach to SOA, modeling, and IT governance. 

One of the key themes at this year's conference is the value of REST.  Jon Flanders is a self-declared Restafarian who went so far as to say that REST was more interoperable that SOAP and is in fact an architecture, not just a pattern and/or protocol.  That certainly got my attention since I certainly didn't share that view walking into the session and initially got me wondering what kind of world he is living in these days.  I wasn't able to catch up with him afterwards, but had dinner with Aaron Skonnard last night where he also shared a similar perspective.

Much of the motivation behind REST is the idea that SOAP is typically an RPC-based approach and has gotten way to complex.  Aaron had a rather insightful comment that massive vendor-support is now actually working against SOAP since a lot of capabilities have been added, for better or for worse.  I certainly agree that SOAP has been pushed way beyond its original intent - Wolf Gilbert once called this process as trying to turn SOAP into a better DCOM (non-Microsoft techies can substitute your proprietary remoting protocol of choice here).  I was initially a bit resistant to SOAP myself because I thought XML over HTTP was quite acceptable for most services - for evidence, please refer to my book "Architecting Web Services" from 2001... if you can find it!  :)  However, I also feel that making a complete cut over to REST from SOAP is also akin to throwing out the baby with the bath water.

Many of the benefits of REST (structured URI's, stateless services, well-defined entities, simple transports) can easily be adopted as good practices by developers of SOAP services.  Some benefits, like caching, are a bit more problematic, but can certainly be done with a little bit of work (this is probably the only real hands-down benefit to REST today, but is still based on certain pre-conditions).  However, some of the negatives (no standard/supported method for metadata exchange, serious security models, or other policies) are absolute show stoppers for many organizations/scenarios.  REST certainly has a place in the industry as evidenced by the widespread adoption in the Web 2.0 world and certain closed systems, but it certainly doesn't work for everyone.  My initial issue with Jon's claim that REST is far more interoperable was that it came with loads of unspoken caveats, as evidenced by his demo that had him grabbing message payloads from Fiddler and indiscriminately choosing which elements in the payload to ignore and embrace in code.  One could make the case that a pipe delimited flat file is more interoperable when you are the consumer AND the provider.  I also found it humorous when he listed all the SOAP-based security bindings and chuckled at how many options there were and blew them all off.  I'd like to see him do that in front of a recent customer of ours where they had no less than three different distributed security models that needed to be supported between various systems.  

My main issue with the Restafarian attitude is that they are addressing some of the development challenges of services, while btw introducing others, and still not really addressing the most pressing deficiencies for other roles in the ecosystem.   We will start making real progress in this area once we transcend this level of debate and move on to the more significant challenges to having ubiquitous, flexible, supportable services.  We need to empower the business to get more involved in the capability creation process and they couldn't understand, much less care about, the distinction between REST and SOAP.  That is an implementation detail and you can easily have it both ways thanks to WCF.  So regardless of which side of the fence you are on, if you think it is the answer, you need to reassess your question.  In my next post I'll share with you the question my team is trying to answer.