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
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
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
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
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
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
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
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.