MVC, I’ll Make a Web API Out of You Yet

One of the great features of .NET Core is the ability to only get the libraries that you want. The designers of .NET Core also wanted to give developers the ability to just get everything and use what you need. With this flexibility comes a bit of confusion, in this case the AddMvc and AddMvcCore middleware configuration functions. I get the feeling I’m going to get sick of the word “Core” over the next few years…

There is no longer any distinction between MVC and Web API in Core. The libraries have merged under the MVC umbrella. I, for one, am happy to see the end of the System.Web.Http and System.Web.Mvc libraries.

The difference between these two functions is AddMvcCore sets up most of what we want if we’re only after a web API. With AddMvcCore, we get controllers, routing, resolvers, most of what we should expect out of a web API. However, if we start up a new ASP.NET Core project and specify a Web API project, we actually get AddMvc.


If we run the application at this point, fresh out the New Project wizard, we’ll see a web page that gives us a bit of JSON out of the values controller that was created.


That seems to work just fine, but what if we want to lighten our dependency load? We can ditch the full functionality of MVC and make it a bit leaner. To do this, we simple have to change line 27 from services.AddMvc() to services.AddMvcCore().

If you’re like me, you like to keep your references list as clean as possible. Maybe it’s a little OCD of me to do it, but it’s something I do regardless. So, at this point, I uninstalled Microsoft.AspNetCore.Mvc.

From here, we could walk through adding the references back one-by-one, but I’ll spare you that and cut to the chase. Think of it like a cooking show where now that I’ve mixed all of our ingredients together, I’m going to pull out a finished one from under the table.

To get back to where we started here is what I needed to reinstall:

Microsoft.AspNetCore.McvCore: Gives us the basics of  a web API functionality.

Microsoft.AspNetCore.Mvc.Formatters.Json: Interprets the response from the server into JSON so the broswer knows what to do with it.

Microsoft.AspNetCore.Mvc.ViewFeatures: Contains the Controller class, critical to the whole thing.

This gives us the simple ability call into a controller that the new project wizard set up for us:


This is all well and good, and a workable controller. However, I like to get a little more out of my controllers. I want to be able to send back an HTTP status code such as Ok, BadRequest, and NotFound. I yearn to return status codes like the .NET Frameworks of yore.

I can get this functionality using IActionResult on each function. These objects are built into the ControllerBase class and allow us to return some more helpful information on our server calls. I’ve modified the default ValuesController to illustrate this. Note that these are not meant to reflect proper responses that web APIs should send back.


So if we fire this up and go to /api/values/0 and inspect the traffic we’ll see that we get an Accept response code rather than a Ok. This is because I’ve changed the Get(int id) function to return the id inside an Accept response.


That’s it! That gets us up and running with a web API, from here we can build out the rest of the functionality that we want from our API. We’ve gone from using a little of a large library down to just what we need: a nice lightweight web API.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s