Understanding Asp .Net MVC Web API
In this blog post we will take a look at the new feature/framework, Asp .Net MVC Web API by Microsoft. Before we dive deep in creating any sample application we will look at Web API in general and benefits of using that and how it is different from other service building options available on .Net stack.
Over the period of time Microsoft has released many frameworks for building services. We have traditional Asp .Net ASMX Web services and then we have WCF. Both of these provides a way for building SOAP based services.When you want to make two applications talk to each other, WCF is the way to go. However, this might not be the right approach in every case !!!!!
Now you might be thinking why is that ? For us to understand this we need to identify primary differences between WCF Services and Asp .Net MVC Web API and when to use one over the other. If you look at the recent trend of web and mobile applications development you find more and more use of JavaScript frameworks like jQuery, Knockoutjs extensively using AJAX mechanism to bring down small chunk of data from server and updating HTML locally on the client instead of posting whole page to the server every time. For example server side validation of a form element in Asp .Net MVC, here.
More over, there are different platforms like iOS and Android which build their platform specific native applications and they mostly rely on some sort of external services. They also try to perform similar calls passing small chunks of data back and forth. And this has created a huge demand for a light weight service type interface that has minimalist approach in terms of security and implementation.
And that is where Asp .Net MVC Web API comes into play. They are designed to tackle exact same problem. Under the hood, Web API is using Asp .Net MVC framework so it leverages all the good things from MVC framework.
Benefits of using Asp .Net Web API
It is REST by default. The routes you used to add in MVC maps seamlessly to controller's Action Methods and provides REST behavior out of the box. Exposing a new operation in your service is as simple as adding a new ActionMethod.
Since it is REST based, the content negotiation happens out of the box by our base ApiController functionality. So if the client is requesting data in JSON format or in XML format you do not have to write special code to handle those cases.
URLs are no longer required to have ActionMethod names included in them. Again, it is REST. Based on the type of request your API is receiving, the request header will have our standard GET,POST,PUT and DELETE Http verbs. These verbs will auto-magically map to the appropriate ActionMethod.
Activating a new service is as simple as putting up a new Controller in your MVC application. There is no complex configurations/bindings involved like we had to do in WCF.
Since it leverages the MVC routing infrastructure, abstraction is much more easier. Providing a newer version of your API is as simple as adding a new route and mapping it to the new Controller, keeping the existing service and it's consumer unchanged and intact.
And most of all, since it is build on HTTP standards, anything that is capable of making HTTP request can reach out to your service. So you can expose your functionality to broader set of clients as opposed to SOAP services.
In future blog posts we will walk through the process of creating a Web API from scratch. Until then have fun.