返回文章列表文章索引阅读全文
STARBLOG / 阅读手记
Asp-Net-Core开发笔记

Asp-Net-Core开发笔记:API版本管理

对于Web API应用程序而言,随着时间的推移以及需求的增加或改变,API必然会遇到升级的需求。事实上,Web API应用程序应该从创建时就考虑到API版本的问题。业务的调整、功能的增加、接口的移除与改名、接口参数变动、实体属性的添加、删除和更改等都会改变API的功能,从而带来版本的变更。

曦远 (DealiAxy)约 22 分钟
目录9 个章节

前言

对于Web API应用程序而言,随着时间的推移以及需求的增加或改变,API必然会遇到升级的需求。事实上,Web API应用程序应该从创建时就考虑到API版本的问题。业务的调整、功能的增加、接口的移除与改名、接口参数变动、实体属性的添加、删除和更改等都会改变API的功能,从而带来版本的变更。

现有的资料大部分是使用 Microsoft.AspNetCore.Mvc.Versioning 这个包,但我实际使用的时候发现这个包早就不更新了,微软官方文档好像也没有这部分介绍,不过在这个包的nuget主页上有说已经换成新的 Asp.Versioning.Mvc 包,原来是微软改名部发力了,失敬失敬~ 😂

好在这个新的包在Github上有很详细的文档,但这改名速度实在是猛,为了实现这个功能,我走了不少弯路。😂

OK,本文基于 .Net6.0,以 AspNetCore WebApi 为例,介绍引入API版本管理的过程。

基础

指定版本的方法有两种,既可以使用[ApiVersion]特性,也可以使用版本约定方式。当定义了不同版本的API接口后,客户端可以通过如下多种方式来访问某一版本的API。

  • 使用URL路径,如 api/v1.0/values
  • 使用查询字符串,如 api/values?api-version=1.0
  • 使用HTTP自定义消息头
  • 使用媒体类型(Media Type)参数,如 Accept: application/json;v=2.0

ASP.NET Core MVC默认的方式是使用查询字符串,查询字符串使用的参数名为api-version。具体使用哪种方式由服务端指定(用下面介绍的 ApiVersionReader 属性来配置),既可以使用其中的一种,也可以同时使用多种不同的方式。

API版本的格式由主版本号与次版本号组成,此外还可以包含可选的两部分:版本组和状态。

  • [Version Group.]<Major>.<Minor>[-Status]
  • <Version Group>[<Major>[.Minor]][-Status]

版本组的格式为YYYY-MM-DD,它能够对API接口起到逻辑分组的作用,状态则能够标识当前版本的状况,如Alpha、Beta和RC等。以下是常见的版本格式:

  • /api/foo?api-version=1.0
  • /api/foo?api-version=2.0-Alpha
  • /api/foo?api-version=2015-05-01.3.0
  • /api/v1/foo
  • /api/v2.0-Alpha/foo
  • /api/v2015-05-01.3.0/foo

本文采用 /api/v1/foo 形式

安装依赖

需要安装这俩nuget包

  • Asp.Versioning.Mvc
  • Asp.Versioning.Mvc.ApiExplorer

注册服务

编辑 Program.cs 文件

builder.Services.AddApiVersioning(options => {
  options.DefaultApiVersion = new ApiVersion(1, 0);
  options.AssumeDefaultVersionWhenUnspecified = true;
  options.ReportApiVersions = true;
  options.ApiVersionReader = ApiVersionReader.Combine(
    new UrlSegmentApiVersionReader(),
    new HeaderApiVersionReader("x-api-version"),
    new MediaTypeApiVersionReader("ver")
  );
})
  .AddMvc()
  .AddApiExplorer(options => {
    options.GroupNameFormat = "'v'VVV";
    options.SubstituteApiVersionInUrl = true;
  });

以上代码做了这些事:

  • DefaultApiVersion 设置默认版本为1.0
  • AssumeDefaultVersionWhenUnspecified 没有指定版本时,使用默认版本
  • ReportApiVersions 在响应头里加上可用的接口版本
  • ApiVersionReader 定义了可以从三个地方获取接口版本信息,URL里和俩请求头
  • GroupNameFormat 指定了版本名称格式,详见下表
  • SubstituteApiVersionInUrl 因为要使用URL指定版本,所以这里设置为true

API Version Format Strings

本文中我使用的是 'v'VVV 的格式

Format SpecifierDescriptionExamples
FFull API version as [group version][.major[.minor]][-status]2017-05-01.1-RC -> 2017-05-01.1-RC
FFFull API version with optional minor version as [group version][.major[.minor,0]][-status]2017-05-01.1-RC -> 2017-05-01.1.0-RC
GGroup version as yyyy-MM-dd2017-05-01.1-RC -> 2017-05-01
GGGroup version as yyyy-MM-dd with status2017-05-01.1-RC -> 2017-05-01-RC
yGroup version year from 0 to 992001-05-01.1-RC -> 1
yyGroup version year from 00 to 992001-05-01.1-RC -> 01
yyyGroup version year with a minimum of three digits2017-05-01.1-RC -> 017
yyyyGroup version year as a four-digit number2017-05-01.1-RC -> 2017
MGroup version month from 1 through 122001-05-01.1-RC -> 5
MMGroup version month from 01 through 122001-05-01.1-RC -> 05
MMMGroup version abbreviated name of the month2001-06-01.1-RC -> Jun
MMMMGroup version full name of the month2001-06-01.1-RC -> June
dGroup version day of the month, from 1 through 312001-05-01.1-RC -> 1
ddGroup version day of the month, from 01 through 312001-05-01.1-RC -> 01
dddGroup version abbreviated name of the day of the week2001-05-01.1-RC -> Mon
ddddGroup version full name of the day of the week2001-05-01.1-RC -> Monday
vMinor version2001-05-01.1-RC -> 1 1.1 -> 1
VMajor version1.0-RC -> 1 2.0 -> 2
VVMajor and minor version1-RC -> 1 1.1-RC -> 1.1 1.1 -> 1.1
VVVMajor, optional minor version, and status1-RC -> 1-RC 1.1 -> 1.1
VVVVMajor, minor version, and status1-RC -> 1.0-RC 1.1 -> 1.1 1 -> 1.0
SStatus1.0-Beta -> Beta
pPadded minor version with default of two digits1.1 -> 01 1 -> 00
p[n]Padded minor version with N digitsp2: 1.1 -> 01 p3: 1.1 -> 001
PPadded major version with default of two digits2.1 -> 02 2 -> 02
P[n]Padded major version with N digitsP2: 2.1 -> 02 P3: 2.1 -> 002
PPPadded major and minor version with a default of two digits2.1 -> 02.01 2 -> 02.00
PPPPadded major, optional minor version, and status with a default of two digits1-RC -> 01-RC 1.1-RC -> 01.01-RC
PPPPPadded major, minor version, and status with a default of two digits1-RC -> 01.00-RC 1.1-RC -> 01.01-RC

设置API版本

例子接口有俩版本

  • /api/v1/demo/test
  • /api/v2/demo/test

在 Controller 下创建俩目录,v1 和 v2,然后分别创建Controller

上代码 Controllers/v1/DemoController.cs

[Route("api/v{version:apiVersion}/[controller]")]
[ApiVersion(1.0)]
[ApiController]
public class DemoController : ControllerBase {
  [HttpGet("[action]")]
  public ApiResponse Test() {
    return ApiResponse.Ok("version=1.0");
  }
}

另一个版本的接口 Controllers/v2/DemoController.cs

[Route("api/v{version:apiVersion}/[controller]")]
[ApiVersion(2.0)]
[ApiController]
public class DemoController : ControllerBase {
  [HttpGet("[action]")]
  public ApiResponse Test() {
    return ApiResponse.Ok("version=2.0");
  }
}

可以看到要区分不同版本的接口,只需要添加 [ApiVersion(2.0)] 特性即可。

因为我要使用URL来选择不同版本的接口,所以要把路由配置为 "api/v{version:apiVersion}/[controller]"

如果不把版本号写在URL里,也可以用请求参数传递,比如 /api/demo/test?api-version=1.0

这些可以在 ApiVersionReader 属性配置

配置Swagger

swagger基本已经是接口文档的标准了,但我发现很多文章都没有介绍swagger这块。(还好官方文档没有忘记)

首先创建一个配置类

public class ConfigureSwaggerOptions : IConfigureOptions<SwaggerGenOptions> {
  readonly IApiVersionDescriptionProvider provider;

  public ConfigureSwaggerOptions(IApiVersionDescriptionProvider provider) =>
    this.provider = provider;

  public void Configure(SwaggerGenOptions options) {
    foreach (var description in provider.ApiVersionDescriptions) {
      options.SwaggerDoc(
        description.GroupName,
        new OpenApiInfo() {
          Title = $"Example API {description.ApiVersion}",
          Version = description.ApiVersion.ToString(),
        });
    }
  }
}

注册服务

builder.Services.AddTransient<IConfigureOptions<SwaggerGenOptions>, ConfigureSwaggerOptions>();

配置中间件

app.UseSwagger();
app.UseSwaggerUI(options => {
    foreach (var description in app.DescribeApiVersions()) {
        var url = $"/swagger/{description.GroupName}/swagger.json";
        var name = description.GroupName.ToUpperInvariant();
        options.SwaggerEndpoint(url, name);
    }
});

效果 & 测试

搞定,访问swagger文档,在右上角接口分组可以看到不同版本

请求 https://localhost:7053/api/v1/Demo/Test

接口返回

{
  "statusCode": 200,
  "successful": true,
  "message": "version=1.0",
  "data": null,
  "errorData": null
}

请求 https://localhost:7053/api/v2/Demo/Test

接口返回

{
  "statusCode": 200,
  "successful": true,
  "message": "version=2.0",
  "data": null,
  "errorData": null
}

不错~ 😃

参考资料

_EOF_

Asp-Net-Core开发笔记:API版本管理

本文作者:
程序设计实验室
版权声明:
本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!

相关文章

Asp-Net-Core开发笔记:快速在已有项目中引入EFCore

很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是 FreeSQL 的话,服务注册的时候是单例模式,只能连接一个数据库,如果需要使用 FreeSQL 同时

2023-10-08 · Asp-Net-Core开发笔记 · 约 1 分钟

Asp-Net-Core开发笔记:使用RateLimit中间件实现接口限流

前言 最近一直在忙(2月份沉迷steam,3月开始工作各种忙),好久没更新博客了,不过也积累了一些,忙里偷闲记录一下。 这个需求是这样的,我之前做了个工单系统,现在要对登录、注册、发起工单这些功能做限流,不能让用户请求太频繁。 从 .Net7 开始,已经有内置的限流功能了,但目前我们的项目还在使用 .Net6 LTS 版本,下一个 LTS 没发布之前,暂时不考虑使用 .Net7 这种非 LTS 版

2023-03-20 · Asp-Net-Core开发笔记 · 约 1 分钟

Asp-Net-Core开发笔记:FrameworkDependent搭配docker部署

之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后直接放到服务器上执行。 这种方式配置完成之后,每次更新只需要重新本地重新 publish 后把可执行文件上传

2023-09-08 · Asp-Net-Core开发笔记 · 约 1 分钟

Asp-Net-Core开发笔记:使用NPM和gulp管理前端静态文件

前言 本文介绍的是AspNetCore的MVC项目,WebApi+独立前端这种前后端分离的项目就不需要多此一举了~默认前端小伙伴是懂得使用前端工具链的。 为啥要用MVC这种服务端渲染技术呢? 简单项目不需要强行分离增加复杂度(如:我正在开发的博客项目) 后端渲染利于SEO,对博客网站友好 OK,虽然MVC的技术老了点,但依然可以结合现代前端工具链来提高效率 本文的食用需要先安装好Node.js环境

2022-02-17 · Asp-Net-Core开发笔记 · 约 1 分钟

讨论

共 0 条

良言一句三冬暖,恶语伤人六月寒。

加载评论中…