前言
梳理了接口变更的八种场景,注意好兼容性哈,大家日常开发中留言一下~~
1. 接口新增入参字段,并且有校验逻辑
我们在日常开发中,经常会遇到的需求就是,在老的接口上,新增入参,
并且需要校验
。
这时候兼容性如何处理呢?我举个简单点的例子:
比如一个用户注册接口,突然加一个
email
的字段并且不能为空,且要校验是否符合邮箱格式
其实可以
升级API版本
,比如
-
创建一个新的API版本,比如/v2/tianluo/register,在这个新版本中包含email字段,并对其进行非空校验。
如果你觉得每次新增个字段和简单校验这种情况,都要升级版本号,比较复杂繁琐,则可以将新字段email设置
为可选
。
如果客户端传了email字段,就对它校验,不传的话,直接放过,然后可以打印一下日志。
if (StringUtils.isNotBlank(userRequest.getEmail())) {
checkEmail(userRequest.getEmail());
}else {
log.info("old system request,email is null,request:{}", userRequest); }
为什么要这么做呢?
我举个例子,如果你修改了接口后,还是有老的请求,不带email字段过来的,站在业务角度,就是可以正常注册的,如果你直接校验拦截,那就有问题啦~~
2. 接口错误码调整
有些时候,我们可能需要对
接口的错误码进行调整
。
如果你调整了错误码,要及时更新接口文档,和通知上下游~~。说明错误码调整的原因。
并且要做兼容性联调测试。
比如你的分布式锁获取失败的错误码,一开始是
423000
。上游依赖这个错误码来
重试
的。
后来你做分布式锁升级优化的时候,你反手把它修改为
666000
了。如果你不通知上下游,联调测试啥的,偷偷改就不管了。那后面肯定出问题,
因为上游获取锁失败,没得重试了,依赖的错误码变更了
。。。
3. 接口返回值调整了
其是不管是
错误码调整还是返回值调整
,都是有共性的。
我们要按照三步曲去走:
比如你们的接口不是联机交易,而是MQ交互的。
你是MQ的生产者,你原来的消息体有个json格式的报文,然后,在本次需求调整了内容。你不及时做好这3步,消费端可能因为你们发版本后,消费不了这个报文(比如解析不了某个特殊返回值)。。。我们以前公司,
出过这种生产案例
,后面我在我的踩坑专栏写出来。
4. 接口参数新增、或者修改了校验
如果你的接口,原来有个字段,比如一开始最大长度是10,然后后来产品需求优化,可以增加到20。然后你觉得这个需求很简单,开开心心,花十分钟改完了,
把入参校验扩大位数,把数据库的字段长度修改
。
后来上线的时候,下游文件核对系统跑失败了。。。因为他们也会对这个字段进行最大长度是10的校验,其实这个也是我们之前遇到的一个bug。
所以做这类型需求的时候,要修改参数校验逻辑的时候。一定要考虑:
兼容性!!上下游是否会有影响等等
。
5. 接口删除,真的没请求访问了吗
有些时候,如果我们发现代码没引用,就会删掉。如果是对外接口的话,不能随手就删掉,
要确认是否还有调用
。