ASP.Net Core中关于WebApi几种版本控制对比详解（图）
这篇文章主要介绍了浅谈ASP.Net Core WebApi几种版本控制对比,小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
一、版本控制的好处：
（1）有助于及时推出功能, 而不会破坏现有系统。
（2）它还可以帮助为选定的客户提供额外的功能。
API 版本控制可以采用不同的方式进行控制，方法如下：
（1）在 URL 中追加版本或作为查询字符串参数,
（2）通过自定义标头和通过接受标头
在这篇文章中, 让我们来看看如何支持多个版本的 ASP.NET Core Web API。
一、创建asp.net core webapi 项目，引用NuGet包：Install-Package Microsoft.AspNetCore.Mvc.Versioning -Version 2.0.0
项目和安装包都好了，接着我们需要在Startup.cs中的ConfigureServices 方法中添加下面的代码：
如您所见, 配置了3不同的选项。
ReportAPIVersions: 这是可选的。但是, 当设置为 true 时, API 将返回响应标头中支持的版本信息。
AssumeDefaultVersionWhenUnspecified: 此选项将用于不提供版本的请求。默认情况下, 假定的 API 版本为1.0。
DefaultApiVersion: 此选项用于指定在请求中未指定版本时要使用的默认 API 版本。这将默认版本为1.0。
这是所有的配置和设置。现在, 我们将看到访问 API 版本的不同方式。
二、通过QueryString来实现版本控制
打开我们的控制器，在上面添加ApiVersion特性，如下代码所示：
上面的代码作为1.0版本。您还可以在不同的命名空间中创建另一个具有相同名称的控制器类, 并将 API 版本设置为2.0版本。如下图所示：
就这样。现在转到浏览器并访问控制器。您应该看到 API 版本1.0 控制器的输出, 因为它被设置为默认值。现在在 URL 中追加 api-version=2, 您应该看到 api 版本2.0 控制器的输出。
二、通过URL Path Segment来实现：
查询字符串参数很有用, 但在长 URL 和其他查询字符串参数的情况下可能会很痛苦。相反, 更好的方法是在 URL 路径中添加版本。比如：
api/v1/values
api/v2/values
还是上面的项目，只不过需要在v1和v2控制器中加入，下面的代码。如下图所示：
同样, 您需要将路由参数更新到所有适用的位置。使用此更改, 在访问API 接口时总是需要有版本号。您可以通过 api/v1/values 访问到版本 1.0, 通过api/v2/values访问版本 2.0, 更改 URL 中的版本号。简单, 看起来更干净了。
测试结果如下：
三、通过HTTP Headers来实现版本控制
在上述两种方法中, 需要修改 URL 以支持版本控制。但是, 如果您希望 api 的URL 保持干净, 则 api 版本信息也可以通过附加 HTTP 报头来传递。要进行此工作, 您需要配置 ApiVersionReader 选项。代码如下：
突出显示的行告诉我们header "api-version" 现在是 api 版本号的预期位置。确保路由属性没有版本详细信息。所以测试它，结果如下：
当您将2.0 作为值提供给 "api 版本" 时, 它将调用版本2.0 控制器并返回输出。
简单, 易于设置。但是, 现在查询字符串参数的方法进行版本控制将不起作用。一旦设置了header, 就不能指定查询字符串参数。如果您希望支持这两种情况, 而不是 HeaderApiVersionReader, 请使用 QueryStringOrHeaderApiVersionReader。代码如下：
因此, 现在支持查询字符串参数和header。默认查询字符串参数名称是 api-version, 因此您可以将构造函数留空, 但如果需要其他名称, 则需要提供。您还可以对查询字符串参数和标头使用有不同的名称。请记住, 我们还将 ReportApiVersions 设置为 true, 该值返回响应标头中的版本信息。见下图。
现在, 让我们来看看另外几个选项。
MapToApiVersion参数的用法：
MapToApiVersion 属性允许将单个 API 操作映射到任何版本。换言之, 一个支持多个版本的单控制器。控制器可能只有版本3支持的 API 操作方法。在这种情况下, 您可以使用 MapToApiVersion。看看下面的代码。
上面代码的意思是：public string Get()该方法只有在版本1.0中支持，public string Getv3()方法只有在版本3.0中支持。
有图有真像，很灵活，我很喜欢。
Deprecated参数的用法：
当支持多个 API 版本时, 某些版本最终会随着时间的推移而被弃用。要标记一个或多个 api 版本已被废弃, 只需用Deprecated修饰您的控制器。这并不意味着不支持 API 版本。你仍然可以调用该版本。它只是一种让 调用API 用户意识到以下版本在将来会被弃用。
上面把Deprecated设置为TRUE表示，版本1.0将来会被弃用。访问我们的API接口，可以在响应头中可以看到，下面信息，如下图所示：
ApiVersionNeutral特性的使用：
ApiVersionNeutral 特性定义此 API 不在支持版本控制。无论 支持api 版本控制或不支持 api 版本控制的旧式 api，这对于行为完全相同的 api 非常有用。因此, 您可以添加 ApiVersionNeutral 属性以从版本控制中退出。
获取版本信息（Version Information）
如果你想知道那个版本的客户端在被访问，你可以通过下面的代码实现该功能：
综上所述, 具有多个版本的 API 可以帮助以一种有效的方式推出增强的功能, 同时也便于跟踪更改。在这篇文章中, 我们看到了如何在 ASP.NET coreWEB API 中添加对多个版本的支持。nuget 包支持通过查询字符串参数进行版本控制, 在 URL 中添加路径段和通过标头。它还具有版本单一 API 操作和从版本中选择退出的功能。
能不能不借助第三方的包来实现一个API的版本控制，方法是有的，不卖关子了，大家接着往下看。
四、终极版本（不借助任何NuGet包）asp.net core web api版本控制
新建一个core API项目：
在VersionControl文件夹下面，新建一个实现了IApplicationModelConvention接口的类NameSpaceVersionRoutingConvention代码如下：
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('.');
//获取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
};
}
}
}调试代码发现这种方式只在程序第一次运行的时候会执行，之后不会再执行多次，因此效率很高。
五、总结：