6. 规范化接口文档
📝 模块更新日志
-
新特性
- 规范化处理自动过滤
SSE
请求、文件请求、图片请求 4.9.1.6 ⏱️2023.11.22 #I8IP6D - 规范化文档枚举支持
[EnumToNumber]
特性配置生成前端枚举定义代码是字符串值还是整数值类型,默认为字符串值 4.8.8.35 ⏱️2023.07.06 #I7IZ7S -
Swagger
分组信息可在任意配置文件中通过[openapi:分组名]
进行配置 4.8.8.26 ⏱️2023.06.20 a70eed3 -
Swagger
请求授权失败后自动退出授权状态 4.8.6.12 ⏱️2023.02.20 !717 -
Swagger
启用登录后配置CheckUrl
可获取本地存储的Authorization
请求报文头 4.8.6.2 ⏱️2023.02.10 #I6E3LB -
Swagger
支持复制路由地址功能 4.8.4.13 ⏱️2023.01.11 #I5VNJI
- 规范化处理自动过滤
-
问题修复
-
Swagger
进行分组后Tags
不能进行分组过滤问题 4.8.8.22 ⏱️2023.05.25 #I78A55 - 因
4.8.7.22
版本导致动态WebAPI
类型注释丢失问题 4.8.7.27 ⏱️2023.03.29 #I6QM23 -
Swagger UI
不显示ControllerBase
派生类注释 4.8.7.22 ⏱️2023.03.27 #I6QM23 - 启用规范化结果后导致
WebSocket
连接断开时出现异常 4.8.7.20 ⏱️2023.03.23 #I6PI5E -
Swagger
接口排序同时指定Tag
和Order
之后无效 4.8.7.2 ⏱️2023.03.01 #I6IQDI #I6IP66 - 规范化结果不带
mini-profiler
版本启动登录UI
后不能传递headers
问题 4.8.6.11 ⏱️2023.02.20 #I6G8IR - 规范化结果不支持
OData
协议控制器 4.8.5.5 ⏱️2023.02.01 !571 - 启用
Swagger
登录功能之后不能触发响应拦截器 4.8.5.5 ⏱️2023.02.01 #I6C9A2 !702 !703
-
-
其他调整
6.1 什么是接口文档
在现在移动为王、多端互辅、前端百花齐放的开放时代,不再是一人包揽式开发,大家各司其职,后端工程师负责接口开发,前端负责接口联调,也就是互联网现在流行的前后端分离架构。
所以就需要由前后端工程师共同定义接口,编写接口文档,之后大家按照这个接口文档进行开发、维护及开放给第三方。
6.2 为什么要写接口文档
- 能够让前端开发与后台开发人员更好的配合,提高工作效率
- 项目迭代或者项目人员更迭时,方便后期人员查看和维护
- 方便测试人员进行接口测试
6.3 为什么需要规范化文档
由于每个公司后端人员技术参差不齐,技术文档能力也不 例外,导致接口定义及文档五花八门,不同项目或不同公司对接极其困难,而且体验糟糕。所以,无规矩不成方圆,为了开发人员间更好的配合,迫切需要整理出一套规范。
通常接口规范分为六个部分:
6.3.1 协议规范
为了确保不同系统/模块间的数据交互,需要事先约定好通讯协议,如:TCP、HTTP、HTTPS 协议。为了确保数据交互安全,建议使用 HTTPS 协议
6.3.2 接口路径规范
作为接口路径,为了方便清晰的区分来自不同的系统,可以采用不同系统/模块名作为接口路径前缀,如:支付模块:/pay/xxx
,订单模块:/order/xxx
6.3.3 版本控制规范
为了便于后期接口的升级和维护,建议在接口路径中加入版本号,便于管理,实现接口多版本的可维护性。如:接口路径中添加类似"v1
"、"v2
"等版本号
6.3.4 接口命名规范
和 C# 命名规范一样,好的、统一的 接口命名规范,不仅可以增强其可读性,而且还会减少很多不必要的口头/书面上的解释。可使用"驼峰命名法"按照实现接口的业务类型、业务场景等命名,有必要时可采取多级目录命名,但目录不宜过长,两级目录较为适宜
常见命名方式
:接口名称动词前/后缀化
: 接口名称以接口数据操作的动词为前/后缀,常见动词有:Add、Delete、Update、Query、Get、Send、Save、Detail、List
等,如:新建用户AddUser
、查询订单详情QueryOrderDetail
。接口名称动词 + 请求方式
:接口路径中包含具体接口名称的名词,接口数据操作动作以 HTTP 请求方式来区分。常用的 HTTP 请求方式有:GET
:从服务器取出资源(一项或多项)POST
:在服务器新建一个资源PUT
:在服务器更新资源(客户端提供改变后的完整资源)PATCH
:在服务器更新资源(客户端提供改变的属性)DELETE
:从服务器删除资源
6.3.5 请求参数规范
请求方式
:按照GET、POST、PUT
等含义定义,避免出现不一致现象,对人造成误解、歧义请求头
:请求头根据项目需求添加配置参数。如:请求数据格式,accept=application/json
等。如有需要,请求头可根据项目需求要求传入用户 token、唯一验签码等加密数据请求参数/请求体
: 请求 参数字段,尽可能与数据库表字段、对象属性名等保持一致,因为保持一致是最省事,最舒服的一件事
6.3.6 返回数据规范
统一规范返回数据的格式,对己对彼都有好处,此处以 json 格式为例。返回数据应包含:返回状态码、返回状态信息、具体数据。返回数据中的状态码、状态信息,常指具体的业务状态,不建议和 HTTP 状态码混在一起。HTTP 状态,是用来体现 HTTP 链路状态情况,如:404-Not Found。HTTP 状态码和 json 结果中的状态码,并存尚可,用于体现不同维度的状态。
6.4 什么是 Swagger
相信无论是前端还是后端开发,都或多或少地被接口文档折磨过。前端经常抱怨后端给的接口文档与实际情况不一致。后端又觉得编写及维护接口文档会耗费不少精力,经常来不及更新。
其实无论是前端调用后端,还是后端调用后端,都期望有一个好的接口文档。但是这个接口文档对于程序员来说,就跟注释一样,经常会抱怨别人写的代码没有写注释,然而自己写起代码起来,最讨厌的,也是写注释。所以仅仅只通过强制来规范大家是不够的,随着时间推移,版本迭代,接口文档往往很容易就跟不上代码了。
发现了痛点就要去找解决方案。解决方案用的人多了,就成了标准的规范,这就是 Swagger
的由来