接口变更常见的八种场景，一定要考虑兼容性呀！

前言

梳理了接口变更的八种场景，注意好兼容性哈，大家日常开发中留言一下~~

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. 接口删除，真的没请求访问了吗

有些时候，如果我们发现代码没引用，就会删掉。如果是对外接口的话，不能随手就删掉， 要确认是否还有调用 。