Learn how to add versioning to ASP.NET Core MVC using pre-built middleware. Nate explains how to install the middleware package, and add it to your application pipeline.
- [Narrator] To add versioning support to the Land and Hotels API, I need to add a NuGet Package to this project. So I'll right click on the project and select manage NuGet Packages. The package I need is called Microsoft.AspNetCore.Mvc.Versioning. The version that I need of this versioning package is 1.10 or greater. At the time of recording this course, that version was still in beta. But, by the time you watch this, it should be stable. I had to check include prerelease to see this beta version, but you shouldn't need to do that.
I'll install this package into my project. And, head over to the startup class to configure it. We'll need to add code to the configure services method. Now that the package is installed, I can do services.AddApiVersioning. And then pass in some options. (typing) This versioning package is really flexible and can support URL versioning, header or media type versioning, and some other styles.
The style I want to use is media type versioning. So I can say opt.ApiVersionReader is a new instance of Media Type API version Reader. I'll need to import a namespace to seed this guy. I can also set some other options. I can say that I want the versioning package to assume the default version if there's no version requested or specified on the request. I can also say that I want the version to be reported in headers in the response.
This is optional, you can turn this on or off. Just to be explicit, I can set the default API version to 1.0. And finally, I can also set the API version selector to a new instance of current implementation API Version Selector. And I need to pass in this options instance again. The current implementation version selector will automatically use the highest or newest version of a route if no version is requested by the client.
Now that I've added this to my startup class, I can go to one of my controllers, such as the root controller, and add a version to this route. (typing) And I can say this is part of the 1.0 version of the API, or I can say it's part of the 2.0 version of the API. Now that I've added this annotation, I can start up the project and then see how it responds with Postman. (mouse clicking) (typing) By sending a Get Request, I can see the headers that come back.
So the Middleware is sending back a header saying that the supported version of the API for this route is this route is 1.0. If I modify my request headers to include the except header, and say that I specifically want, as the client, to request a different version of the API, I want ion plus JSON version 2.0. Try to send that request. I'll get a 400 error that basically says it doesn't support API version 2.0 on this route. If I back that down to 1.0, then I'll get a response that's good.
Because that is one of the supported versions for this route. And this versioning can be customized on a per route or even per method basis. So now we're able to version the API if we need to. But otherwise, the versioning system will stay out of the way.
- REST vs. RPC
- Using HTTP methods (aka verbs)
- Returning JSON
- Creating a new API project
- Building a root controller
- Routing to controllers with templates
- Requiring HTTPS for security
- Creating resources and data models
- Returning data and resources from a controller
- Representing links (HREFs)
- Representing collections
- Sorting and searching collections
- Creating forms
- Caching and compression
- Authentication and authorization for RESTful APIs