On The Coexistence of ASP.NET MVC and WebAPI

Monday, July 1, 2013

I’ve gotten more than a few questions over the last year on how to use the ASP.NET MVC framework and the Web API framework together. Do they work together? Should they work together? When should you use one or the other?

Here’s some general rules of thumb I use.

1. If the bulk of the application is generating HTML on the server, then there is no need to use the Web API. Even if I have the occasional call from JavaScript to get JSON data for templates or an autocomplete widget, using regular MVC controllers will suffice.

All ASP.NET MVC

One thing to keep in mind is that the Web API is a separate framework with its own dependency resolver, action filters, routing rules, model binding, and model serialization settings. Bringing in a 2nd set of all these components just to satisfy a few JSON requests from script is an increase in complexity.

2. If an application is loaded with JavaScripts and JSON flows back and forth to the server frequently, or if I have to support more clients than just the script in the pages from my site (some of whom might want XML or other formats), then it is a good time to create HTTP service endpoints and a more formal service API. These scenarios are just what Web API is made for and both MVC controllers and Web API controllers will happily coexist in the same project.

MVC With Web API

Although the Web API does add some complexity, it is also easier to build a proper service with the Web API. I can use the verb based routing and content negotiation features to build services oriented around resources, and the OData support and automatic help page generation of the Web API framework can come in handy.

3. I’m not a big fan of services for services sake. In the previous two figures, the MVC UI and Web API pieces are drawn to suggest how they are only facades on top of a core application. Most of the interesting things are defined in the application and not in the UI and Web API layers. When someone suggests that the MVC controllers should talk over HTTP to Web API controllers in the same application, all I can think about is putting a façade over a façade, which seems silly.

 

Tears for tiers

There are some valid reasons to go with such an architecture (see #4), but be cautious when creating new tiers.

4. It is more than reasonable to integrate multiple applications or large pieces of functionality using services and the Web API. This is a scenario where having web service calls inside or behind the MVC controllers of an application is almost required.

Big Enterprise

The above type of scenario usually involves large applications and multiple teams. Using a service layer allows for more flexibility and scale compared to sharing binaries, or integrating at the database level (shudder with fear).

Parting Words

There is no quick and easy answer to the questions in this space. If you are looking for guidance, hopefully I’ve provided some rules of thumb you can use to start thinking about the answer for your specific scenario. While thinking, remember these lines from the Zen of Python:

Simple is better than complex

Complex is better than complicated


Comments
gravatar Haris Monday, July 1, 2013
How about MVC just for view rendering and then all the calls for JSON goes to WebAPI?
gravatar Scott Monday, July 1, 2013
@Harris: Yes, scenario 1 or 2, depending on how much you have to expose with JSON. It's a judgement call.
Brian Knight Monday, July 1, 2013
Thanks for your comments on #3. I think that pattern is used way too often without justification.
gravatar Santos R. Victorero Monday, July 1, 2013
Very nice analysis! I understand that this post is about the coexistence of ASP.NET MVC and WebAPI but in some cases I have completely eliminated ASP.NET MVC and use only the WebApi with an initial index.html as a SPA.
Erick Monday, July 1, 2013
I kind of understand why they did it, but introducing a whole new set of infrastructure that is essentially the same, but completely incompatible seemed like a terrible move, Re: [dependency resolver, action filters, routing rules, model binding, and model serialization settings]
gravatar Wyatt Barnett Monday, July 1, 2013
I don't think it helps much that the default template for MVC4 includes both a MVC site and a web API endpoint. This also changes a bit for vNext -- it seems the new unified ASP.NET will handle this better though I didn't get time to get into the details.
gravatar Anthony Johnston Tuesday, July 2, 2013
Also #3 and #4 allow for a good team separation, even if there is only 2, the backend done by one guy using webapi and the frontend simple mvc and fancy js ..and as in #4 allows for expansion to other devices and platforms I agree, no right answer, but good to know a number of possible solutions.. thanks for the sum-up
gravatar Matt Wednesday, July 3, 2013
Slightly off topic, but what would be your thoughts on a Web Forms application that makes little use of server controls but is heavy on jquery ajax calls returning json by way of: (1) Web API, or option (2) page methods in code behind?
gravatar ENOTTY Tuesday, July 9, 2013
@Matt: re Web Forms & jquery ajax FWIW, I use a WCF (ASP.NET compatible) endpoint since I'm weird like that (and on .NET 3.5).
gravatar Ihor Wednesday, July 17, 2013
Thanks for nice explanation, my friends have chosen WebApi instead of MVC and now they have so much problems...
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!