ASP.NET MVC Controller Vs. Web API - 5 Things You Should Know
ASP.NET MVC allows you to expose functionality through action methods. One
can also expose the functionality as a Web API. Beginners often find it
confusing to decide when to go for an MVC controller driven approach and when to
go for a Web API. Here are five main considerations that can be helpful while
taking a decision.
1. Expose functionality within a Web Application or create a full-fledged
The basic consideration is whether you wish to expose a functionality within
one specific application or you wish to expose it as a generic functionality
independent of any specific application. In the former case ASP.NET MVC
controllers may serve your needs. A controller is usually tied to a one
particular web application. It can expose functionality that can be quickly
consumed through Ajax. Instead of creating a whole new API this controller based
approach can be quick and easy for exposing functionality for a given web
application. The later approach is good if you wish to create a full-fledge REST
service that is not tied to just a single application. Many client applications
want to consume this service to get their job done. In such cases a Web API
offers a more elegant and neat solution. Generally speaking if your
functionality is data centric (for example, CRUD operations) then Web API serves
well whereas if your functionality is UI/View centric (loading HTML fragments,
Ajax driven pages) then MVC controllers are a natural choice.
2. What data formats you want to deal with?
A controller usually returns ActionResult or JsonResult. That means the
output of a controller is typically HTML markup or JSON formatted data. If these
data formats suffice your needs then action methods can be used to expose your
functionality. However, if you need multiple data formats such as XML and JSON
then Web API allows an easy way to configure them. Web API decides the data
format automatically based on the Accept header. MVC controller, on the other
hand, requires you to explicitly specify the data format (ActionResult or
JsonResult) while writing the action methods.
3. Do you need content negotiation?
Content negotiation refers to returning content in a format as indicated by
Accept header. Using Web API you can send content to the client in variety of
formats such as images or files (not just XML or JSON). Although this is a nice
features for an API framework such as Web API, not all applications need it. In
most of the cases sending data as JSON or XML is what you need. So, this feature
of Web API won't be of much use to you if you are sending data to and from a
client. To know more about content negotiation
go here and
4. Do you need self-hosting?
If you expose a functionality through a controller, you must host it in IIS.
This is obvious because controller is part of your ASP.NET MVC application and
requires IIS as the hosting environment. Web API being a service framework allow
you to host an API in a custom host (self-hosting). In this case you can avoid
overheads of IIS and host a Web API in a lightweight custom host. This is
typically used where a service is to be consumed by wide array of clients such
as desktop applications, web applications and/or even console applications.
5. How important are the method signatures?
By default Web API uses HTTP verb based mapping for invoking methods. For
example, if you make a request with POST verb then Web API will invoke its
PostXXXX() method. Moreover, all the request data is wrapped in a single
parameter and passed to the method under consideration. This makes the Web API
action names and signatures bit rigid. You cannot, for example, have a method
that has, say, five parameters. Similarly you can't have multiple methods for a
same HTTP verb (except GET where you can have two methods). So, to develop a Web
API you need to be aware of these design restrictions. In case of MVC
controller, you don't have such restriction. MVC model binding takes care of
mapping the request data with the appropriate parameters of an action method.
These are just some of the primary considerations that will help you evaluate
a given scenario. You can also use both the techniques in a single web