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.