ASP.NET Web API Intoduction

ASP.NET Web API is framework built on top of ASP.NET, for building RESTful applications on .NET Platform. These are intended to return data in the form of JSON/XML etc  rather than HTML markup. This can be used to create HTTP services that only use the standard HTTP concepts (URIs and verbs), and to to create services that use more advanced HTTP features – request/response headers, hypermedia concepts etc.

Some Key features
. Support for MVC style URL routing
. Content Negotiation based on Accept headers (Content-Type: application/json or xml etc) for request and response serialization.
. Easily extensible Formatter, default is JSON.NET. Refer to http://json.codeplex.com/ for feature comparison
. MVC style convention-over-configuration
. Easily extensible similar to MVC
. Testable using testing concepts similar to MVC
. Parameter binding(using model binding and formatter)
. This framework borrows a lot of concepts from ASP.NET MVC.


With earlier version of Mvc there is an option of calling Controller.Json Method, which creates a JsonResult object that serializes the specified object to JSON format. Also there is an option of writting custome Xml Action result and similarly for any other format. But this doesn't provide a  way to automatically negotiate content types and serve various content formats directly.

Other option is WCF service with the use of webHttpBinding. In spite of complicated configuration, I like this framework specially for the reason this is designed for transport independent. This bring to an important point in choosing between WCF and ASP.NET Web API. If you need service which need to support multiple transport protocol, Wcf is a way to go, but if you are designing service only for HTTP, then Web API could be a better option as it has less complicated configuration, little simpler in terms of use of attributes (for specifying verb,Uri) and support for testing as this was an important goal throughout the design and development around ASP.NET MVC. Also WCF was primarily designed for SOAP-based XML messages. I ran into few problems in past around this as example I was having operation which was throwing FaultException (System.ServiceModel). This works great as long as I was using this for SOAP but when I started using the same service for end point with webHttpBinding, I was not getting desired behaviour. Later on I realised that for this to work nicely with webHttpBinding I need to throw WebFaultException(System.ServiceModel.Web). So I finally moved this error handling as a part of endpoint behaviour to make my serivce transport independent. Refer to my WCF blog on detail solution.

Using raw HTTP Handlers and Modules in the core ASP.NET runtime is also one option but you have to do pretty much every thing by hand.

Web API is similar to MVC but not the Same. Coming with mind set of ASP.NET Mvc I struggled a lot for following difference. I am still not sure why there is difference in behavior.
. You cannot have two action parameters to be bind from body. Similar to ASP.NET Mvc I was expecting this to work. Refer to my blog on parameter binding for detail on this.
. ActionFilter are designed differently. API uses System.Web.Http.Filters.ActionFilterAttribute where as MVC uses System.Web.Mvc.ActionFilterAttribute. This means if you implement an MVC ActionFilter and you want that same functionality in your Web API you'll end up creating the filter twice.