Implementation of SOA WCF-REST style Vs ASP.NET WebAPI

Implementation of SOA: WCF-REST style Vs ASP.NET WebAPI

The problem with the WCF framework was that it involved a lot of configuration, even if you had to configure simple REST services because it was originally built for SOAP and generalize to be consumed over various platform, channels & protocols. Along the way, the ASP.NET Microsoft teams were working on a very elegant architecture, the ASP.Net MVC framework which makes it very easy to make HTTP requests/responses using the easy-to-create controllers.

Is it really a problem with well trained WCF developer? I feel its only one time effort. Lets understand it using some comparison: First we see some advantages and disadvantages of WCF.

Advantages:

• WCF reduces the plumbing time.
• WCF is more versatile than Web API. WCF Service support various bindings can be consumed through many channels like HTTP, TCP, UDP, MSMQ etc. So when there a requirement of consuming your services with different kind of transport / protocol than WCF should be your obvious choice.
• Developer concentrates on what he wants to achieve and WCF takes care of delivering it to the outer world in the most reliable, secure and high performance fashion. With some small configuration changes we can implement security and change of binding.
• Hosting: Supports various hosting option, like IIS, WAS, with in EXE, Windows Services using self hosting feature.
• I can maintain state for many of the binding available.
• It support various behavior for concurrency and throttling
• It supports streaming 
• It supports automic transaction
• It supports load balancing and scaling.
• Inherently support logging

Disadvantages:

• As its a proprietary technology of Microsoft, so its interoperatibility with other technologies / platform is quite tough.
• It consumes additional processing power and memory in comparison with its alternative because of additional abstraction layer.
• A bit of learning curve is required for implementation and configuration of WCF.

When to use WEB API:

• If you're focused on exposing services which will most probably be consumed by a browser platform, the RESTful services is probably the way to go. 
• If your developers are acquaintance with ASP.NET MVC than moving to ASP.NET Web API would be good, as it follows same pattern and structure of MVC.
• Its open source and you will get the updates more frequently than the .NET framework updates.

Till now we have discussed pros and cons of WCF but in particular to RESTful services question is:

WHAT IS MISSING IN WCF REST AND WHY WCF REST IS NOT TRUE REST?

Some facts which shifted the thinking of developers to move over ASP.NET WEB API:

• In the industry experts have seen that majority of WCF services are consumed over HTTP protocol. HTTP is ubiquitous and it’s lightweight.  Every consumer that connects to the web understands it, every browser supports it, and the infrastructure of the world wide web is built around it. Developer community using WCF asked for better control over HTTP and consuming it with web toolkit like jQuery. That is the primary reason why WEB API came into existence.
• People don't care about the SOAP, but they need wider reach, so that their  customer can consume the services across devices without any hurdles like installing some software or cross the boundaries of firewall to consuming the services.
• Services should be lightweight. 
• ASP.NET WEB API supports full power of HTTP protocol like caching, etags, if-not-modified-since etc.
• ASP .NET WEB API has a very good architecture, pattern based development. very easy to setup for unit testing. Seamless support for IoC, which makes it perfect for loose coupled design.
• ASP.NET WEB API supports a very rich set of resources (media types). You can enable support for your own media type using RAZOR engine customization like if you want your services to return vCard or iCal data formats or any any other scientific data (like Geocode). You need not to convert them inteado a generic form of SOAP. It is very easy for services to support multiple formats on a single service. 
• Seamless integration with AJAX and JSON
• Most suitable for simple tasks.
• Better supports for ODATA & Queryable

Below are some REST constraint which are elegantly covered by ASP.NET WEB API:

• Client-Server - 
• Stateless - Does not support ASP.NET session inherently
• Cache - using request header & url server can identify and can send cached data
• Uniform interface - different HTTP verbs (GET, PUT, POST, DELETE) for various operation is uniform across all consumer
• identification of resources - using URL one can identify any resource uniquely
• Self-descriptive messages -  
• Manipulation of resources through representations - Methods like GET, PUT, POST & DELETE
• Hypermedia as the engine of application state - Razor engine satisfies most of the requirements, if needed one can inject some custom engine for different presentation.
• Layered system - Major concerns are seperated well.
• Code on demand - Can consume services using JavaScript.

If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.