Shulou(Shulou.com)06/03 Report--

This article mainly introduces the example analysis of several kinds of version control comparison of WebApi in ASP.Net Core, which is very detailed and has certain reference value. Friends who are interested must finish it!

This article mainly introduces the comparison of several kinds of version control of ASP.Net Core WebApi. The editor thinks it is quite good. Now I share it with you and give you a reference. Let's follow the editor and have a look.

1. Benefits of version control:

(1) it helps to launch functions in a timely manner without damaging the existing system.

(2) it can also help provide additional functionality for selected customers.

API version control can be controlled in different ways as follows:

(1) append the version in URL or as a query string parameter

(2) by customizing headers and by accepting headers

In this article, let's look at how to support multiple versions of ASP.NET Core Web API.

First, create an asp.net core webapi project and reference the NuGet package: Install-Package Microsoft.AspNetCore.Mvc.Versioning-Version 2.0.0

The project and the installation package are ready, and then we need to add the following code to the ConfigureServices method in Startup.cs:

As you can see, three different options are configured.

ReportAPIVersions: this is optional. However, when set to true, API returns the version information supported in the response header.

AssumeDefaultVersionWhenUnspecified: this option will be used for requests that do not provide a version. By default, the assumed version of API is 1.0.

DefaultApiVersion: this option is used to specify the default API version to use if no version is specified in the request. This will set the default version to 1.0.

This is all the configuration and settings. Now we will see different ways to access the API version.

Second, version control is realized through QueryString

Open our controller and add the ApiVersion feature to it, as shown in the following code:

The above code is as version 1.0. You can also create another controller class with the same name in a different namespace and set the API version to version 2.0. As shown in the following figure:

That's all. Now go to the browser and access the controller. You should see the output of the API version 1.0 controller because it is set to the default value. Now append api-version=2 to URL, and you should see the output of the api version 2.0 controller.

Second, through URL Path Segment to achieve:

Query string parameters are useful, but can be painful in the case of long URL and other query string parameters. Instead, a better way is to add a version to the URL path. For example:

Api/v1/values

Api/v2/values

It's the same project above, but you just need to add the following code to the v1 and v2 controllers. As shown in the following figure:

Again, you need to update the routing parameters to all applicable locations. With this change, a version number is always required when accessing the API interface. You can access version 1.0 through api/v1/values and version 2.0 through api/v2/values to change the version number in URL. It's simple. It looks cleaner.

The test results are as follows:

Third, version control is realized through HTTP Headers

In both of the above methods, URL needs to be modified to support versioning. However, if you want api's URL to be kept clean, api version information can also be passed by attaching HTTP headers. To do this, you need to configure the ApiVersionReader option. The code is as follows:

The highlighted line tells us that header "api-version" is now the expected location of the api version number. Make sure that the routing properties do not have version details. So test it, and the results are as follows:

When you supply 2.0 as a value to the "api version", it invokes the version 2.0 controller and returns the output.

Simple and easy to set up. However, versioning by the method of querying string parameters will not work now. Once header is set, you cannot specify query string parameters. If you want to support both scenarios instead of HeaderApiVersionReader, use QueryStringOrHeaderApiVersionReader. The code is as follows:

Therefore, query string parameters and header are now supported. The default query string parameter name is api-version, so you can leave the constructor blank, but if you need another name, you need to provide it. You can also use different names for query string parameters and headers. Remember, we also set ReportApiVersions to true, which returns the version information in the response header. See the picture below.

Now, let's look at a few other options.

Usage of the MapToApiVersion parameter:

The MapToApiVersion attribute allows a single API operation to be mapped to any version. In other words, a single controller that supports multiple versions. The controller may only have the API operation methods supported by version 3. In this case, you can use MapToApiVersion. Look at the following code.

The above code means: public string Get () this method is only supported in version 1.0, and the public string Getv3 () method is only supported in version 3.0.

There are pictures and real images. They are very flexible. I like them very much.

Usage of the Deprecated parameter:

When multiple API versions are supported, some versions will eventually be deprecated over time. To mark one or more api versions as obsolete, simply decorate your controller with Deprecated. This does not mean that the API version is not supported. You can still call this version. It is just a way to make the calling API user aware that the following version will be deprecated in the future.

Setting Deprecated to TRUE above indicates that version 1.0 will be deprecated in the future. If you visit our API API, you can see the following information in the response header, as shown in the following figure:

Use of the ApiVersionNeutral feature:

The ApiVersionNeutral feature defines that this API no longer supports versioning. This is useful for api with exactly the same behavior, whether it supports api versioning or legacy api that does not support api versioning. Therefore, you can add the ApiVersionNeutral attribute to exit from version control.

Get version information (Version Information)

If you want to know which version of the client is being accessed, you can do this with the following code:

To sum up, multiple versions of API can help roll out enhanced functionality in an effective way, while also making it easy to track changes. In this article, we saw how to add support for multiple versions of ASP.NET coreWEB API. The nuget package supports versioning through query string parameters, adding path segments and passing headers in URL. It also has a version of a single API operation and choose to exit from the version.

Can you achieve a version control of API without the help of a third-party package? there are ways to stop selling, so let's move on.

Final version (without any NuGet package) asp.net core web api version control

Create a new core API project:

Under the VersionControl folder, create a new class NameSpaceVersionRoutingConvention that implements the IApplicationModelConvention interface as follows:

Public class NameSpaceVersionRoutingConvention:IApplicationModelConvention {private readonly string apiPrefix; private const string urlTemplate = "{0} / {1} / {2}"; public NameSpaceVersionRoutingConvention (string apiPrefix = "api") {this.apiPrefix = apiPrefix;} public void Apply (ApplicationModel application) {foreach (var controller in application.Controllers) {var hasRouteAttribute = controller.Selectors .any (x = > x.AttributeRouteModel! = null) If (! hasRouteAttribute) {continue;} var nameSpaces = controller.ControllerType.Namespace.Split ('.'); / / get the version number in namespace var version = nameSpaces.FirstOrDefault (x = > Regex.IsMatch (x, @ "^ v (\ d +) $"); if (string.IsNullOrEmpty (version)) {continue } string template = string.Format (urlTemplate, apiPrefix, version, controller.ControllerName); controller.Selectors [0] .AttributeRouteModel = new AttributeRouteModel () {Template = template};}

Debugging code finds that this method is efficient because it is executed only the first time the program is run, and not many times after that.

The above is all the contents of this article entitled "sample Analysis of the comparison of several version controls of WebApi in ASP.Net Core". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.