软件系统在整个生命周期当中会根据需求的不断变化进行不断的迭代更新,因此服务端对外提供的接口尽管功能未发生变化,但是实现的逻辑,代码也在不断的变化。如果只是简单的变化,对于接口调用者来说是无感知的,但是通常会出现一些突破性的变化,例如:
- 接口新增字段
- 接口字段类型变更
- 接口字段由非必传变成必传
上述情况的出现,对于接口调用者来说必然是存在强烈感知的,通常为了减少接口调用者的感知,服务端代码就存在同样功能的接口,多个版本的情况,就出现了接口版本控制这个问题。
版本控制及实现方式:
1、请求参数控制
例如在HTTP请求当中不修改请求路径的情况下添加参数:
在请求的参数当中添加版本参数: HTTP://XXX.COM?version=1
在请求头HEADER当中添加版本参数:version:1
在请求头Content-Type: application/v1.json
以上三种均可以在请求参数当中进行版本的控制,并且不修改请求路径,相关代码实现如下:
@GetMapping(value = "test",params = {"version=1"},headers = {"version=1"},consumes = {"Content-Type=application/v1.json"})
public String getT2() {
return "123456";
}
2、URL路径控制
即版本是请求URL的一部分:例如:/v1/api/getUser, /api/getUser/v1。
3、域名服务控制
即请求路径不变,域名发生变化:v1.api.hjljy.cn/getUser,v2.api.hjljy.cn/getUser
总结
无论选用哪一种实现方式,同一个功能的接口版本不宜过多,避免造成较高的维护成本,同时尽可能的保证接口版本的稳定性和可读性(便于查找和排错)
{{item.user_info.nickname ? item.user_info.nickname : item.user_name}}
作者 管理员 企业
{{itemf.name}}
{{itemc.user_info.nickname}}
{{itemc.user_name}}
回复 {{itemc.comment_user_info.nickname}}
{{itemf.name}}