"Go" ASP version control

A few days ago, my friends and I developed an API using the ASP. NET Core, which uses the Get method to return some data to the client APP. We paged at the front end, which means we send all the data to the client and then do something data.length to get the items count paging logic. To reduce the load on HTTP requests, we decided to implement logic on the backend (server-side paging). In our case, this is no problem, because we can quickly implement it on the client. We have modified all the logic on the client and the server, and have done all the functions quickly.

However, you may have other clients in use because only one data source (API) is provided. Introducing breakthrough changes in one API can support one client, but it also destroys other clients. For example, suppose your mobile team is on vacation and your WEB team is working to support the server-side paging feature. To support the Web team, you made a simple change in the API. This change, you and your Web team are happy (clap your hands if you feel happy). The nightmare begins, and you will find that because of a very simple (and actually groundbreaking) change, the millions of mobile client does not work and the user uninstalls the app. When you find that you are not a mobile application developer and have no access to source code permissions, more nightmares come. Now you can only choose to downgrade your APIs and Web applications, but the Web application development team is now on vacation. Because more nightmares will follow, all things can only stagnate.

Maybe (not maybe, it is!) API version control is a very good choice in this case. With API versioning, you can not only safely target these groundbreaking changes, but also support these changes, which is a win for everyone.

Let's take a look at how to configure the API version in ASP.

Note : I am using an empty ASP. NET Core Web API project (. NET Core 1.1)

Install this package through NuGet: Microsoft.AspNetCore.Mvc.Versioning. Now, Startup.cs ConfigureServices() Configure the service () in the method of the class services.AddApiVersioning() :

public void ConfigureServices(IServiceCollection services){    services.AddMvc();    services.AddApiVersioning();}

When you are using a Microsoft.AspNetCore.Mvc.Versioning 1.1.1 version, you only need to use the app.UseApiVersioning() method:

public void Configure(IApplicationBuilder app, IHostingEnvironment env,                       ILoggerFactory loggerFactory){    /* garbage code removed */    app.UseMvc();    app.UseApiVersioning();}

Next, you must use ApiVersion a controller (multiple versions) that defines the API version control to support. Similarly, you must also use the MapToApiVersion define specific Action API version number:

[apiversion ( "2.0" )][route ( "Api/[controller]" )]public  class  valuescontroller : controller  {//GET api/values  [maptoapiversion (" 1.0 ")] [HttpGet] public  ienumerable<string  > get  ()  {return  Json (new  string  [] { "value1"    ,  "value2" }); }}

Now GET , by way of invocation Action , you must specify the API version and temporarily use the query string versioning method. This allows you to specify the API version directly in the query string. For example this: http://localhost:5000/api/values?api-version=1.0.

If you add API version control to an existing API project, you can tell ASP. NET Core to treat the default controller and action as versioned 1.0 . To do this, the configuration AddApiVersioning() service looks like this:

true);

You can now call the API like this http://localhost:5000/api/values, without causing any errors.

There are three ways to specify the API version:

• Query characters (discussed already)
• URL path
• Media type

With a URL path, you can pass the version number as part of the URL path. Examples like this are http://localhost:5000/api/v1/values. By the way, you must modify your route properties to accommodate the version segment as follows:

[ApiVersion("1.0")][Route("api/v{version:apiVersion}/[controller]")]publicclassValuesControllerController{    [HttpGet, MapToApiVersion("1.0")]    public IActionResult Get()    {        return Json(newstring"value1""value2" });    }}

Note that the letter v is not mandatory to be added before the version number, which is only a convention.

Finally, you can configure the service to read the API version number from a specific media type (by default, read from the Content-type media type, and you can configure your own media type). Configure your service to activate the media Type version control as follows:

public void ConfigureServices(IServiceCollection services){        // Add framework services.    services.AddMvc();    services.AddApiVersioning(options =>    {        new MediaTypeApiVersionReader();        true;        new CurrentImplementationApiVersionSelector(options);    });}

Now, when you send an HTTP request, specify the API version number in the request header content-type , as follows (content-type:application/json;v=2.0):

By the way, using CurrentImplementationApiVersionSelector , if no version is content-type defined in the media type, the latest API version will be used. In the following example, I did not mention any version number, so it uses the latest version in all versions.

That's not all, and there are other cool features that you can find in Microsoft's ASP. Versioning git repository: https://github.com/ Microsoft/aspnet-api-versioning/wiki.

Found an article of the same type, explained in more detail, for your reference: http://www.talkingdotnet.com/support-multiple-versions-of-asp-net-core-web-api/.

Original address: Https://www.codeproject.com/Tips/1197505/ASP-NET-Core-API-Versioning-in-Simple-Words-Update
Translation: Sweet Tang
This address: http://www.cnblogs.com/tdfblog/p/asp-net-core-api-versioning.html
Welcome reprint, please give the source and link in obvious position.

"Go" ASP version control