REST versus SOAP (ASP.NET MVC versus WCF)

I am evaluating/designing a new SOA architecture core system. I have spent few days on playing with both REST (particularly in ASP.NET MVC) and SOAP (WCF). And I am leaning towards a conculsion that they should NOT be mutually exclusive, as SOA is not only built for the current, but also for the unforseen future. Here is a snapshot of what I've learnt from both and hopefuly it helps you to make your decision.

• REST (ASP.NET MVC):
  • Pros:
    • Reuse the successful web model - http + five verbs
    • Resource based
    • Loosely coupled - no contract dependency, thus, less lengthy maintenance work.
    • A natural fit to DDD (Domain-Driven-Development) - app services can be REST services if no more abstraction is needed
    • A given to build public/cloud services
    • Messages are lightweight compared to SOAP - FAST!
    • Much better compatibility - as long as you client can make web/client requests
    • ASP.NET MVC provide a good foundation to render restful services thru controllers or views (if more complex format support is required)
  • Cons:
    • Stateless
    • No transaction capability
    • Manual work to de-serialise responses back to objects - as far as I am aware
    • Poor tooling support for client proxy generation in .NET - except if we use the latest WCF 3.5 SP1 REST support, but I wouldn't consider it as true REST as they are still contracts dependent.
    • No rich WS-Security support (of course) - whatever security strategy works for HTTP model will work for REST
    • Locked to HTTP transport protocol
• SOAP (WCF)
  • Pros:
    • Less mind-shift curve for people who love good-old-days of .NET2.0 web services, WSE.
    • Rich out-of-box WS-Secruity model - Those out-of-box security strategies are usually adequate for 80% of apps
    • Stateful
    • Support transactions
    • Great VS IDE support for services creation
    • Great client proxy tooling support to generate client reference code with typed objects
    • Build-in error handling
    • Good for distributed systems where remote objects are accessble by different systems with ability to maintain their states and transactions.
  • Cons:
    • Contract dependency - The concept of having contract sitting in between clients and services is fine, maybe should be encouraged in a way. But because these contracts are typed interfaces, therefore, every time if a contract is changed, all the depending clients need to be recompiled, this could a painful process - and kinda against the idea of SOA - server should be loosely coupled
    • Action-Oriented - Each service entry point is an action with business logic behind, not object-oriented. Therefore, we probably won't gain much benefit from our rich domain thru DDD from service access perspective.
    • More heavy-weight and verbose than REST
• Hybrid
  • WCF 3.5 SP1 REST Support - Still highly couple with contracts, not a true REST, not a true WCF either :-(
  • WCF Rest Starter Kit (CTP) - Got potential in terms of tooling support and true REST model (not relying on contracts), but it's still in preview phase at the moment :-(
  • Use ASP.NET MVC for REST and make sure the model can also be easily utilised in WCF. The main reasons are: we have windows clients, batch processes and up-coming new systems to support, this dynamic eco system has decided that WCF should defintely not be excluded as one of key fundemental technologies at this stage.

Conculsion:

Using ASP.NET MVC for REST and make sure the model can also be easily utilised in WCF. This is probably the likely option we will adopt.