聊聊接口设计的36个小技巧

前言

大家好，作为后端开发，不管是什么语言，Java、Go还是C++，其背后的后端思想都是类似的。后面打算出一个后端思想的技术专栏，主要包括后端的一些设计、或者后端规范相关的，希望对大家日常工作有帮助哈。

我们做后端开发工程师，主要工作就是：如何把一个接口设计好。所以，今天就给大家介绍，设计好接口的36个锦囊。本文就是后端思想专栏的第一篇哈。

小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我，后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备！
所有资料都整理到网盘了，需要的话欢迎下载！私信我回复【111】即可免费获取

1. 接口参数校验

入参出参校验是每个程序员必备的基本素养。你设计的接口，必须先校验参数。比如入参是否允许为空，入参长度是否符合你的预期长度。这个要养成习惯哈，日常开发中，很多低级bug都是不校验参数导致的。

比如你的数据库表字段设置为varchar(16),对方传了一个32位的字符串过来，如果你不校验参数，插入数据库直接异常了。

出参也是，比如你定义的接口报文，参数是不为空的，但是你的接口返回参数，没有做校验，因为程序某些原因，直返回别人一个null值。。。

​

添加图片注释，不超过 140 字（可选）

2. 修改老接口时，注意接口的兼容性

很多bug都是因为修改了对外旧接口，但是却不做兼容导致的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~

​

编辑

添加图片注释，不超过 140 字（可选）

所以，如果你的需求是在原来接口上修改，尤其这个接口是对外提供服务的话，一定要考虑接口兼容。举个例子吧，比如dubbo接口，原本是只接收A，B参数，现在你加了一个参数C，就可以考虑这样处理：

//老接口
void oldService(A,B){
  //兼容新接口，传个null代替C
  newService(A,B,null);
}

//新接口，暂时不能删掉老接口，需要做兼容。
void newService(A,B,C){
  ...
}

//老接口 void oldService(A,B){ //兼容新接口，传个null代替C newService(A,B,null); } //新接口，暂时不能删掉老接口，需要做兼容。 void newService(A,B,C){ ... }

3. 设计接口时，充分考虑接口的可扩展性

要根据实际业务场景设计接口，充分考虑接口的可扩展性。

比如你接到一个需求：是用户添加或者修改员工时，需要刷脸。那你是反手提供一个员工管理的提交刷脸信息接口？还是先思考：提交刷脸是不是通用流程呢？比如转账或者一键贴现需要接入刷脸的话，你是否需要重新实现一个接口呢？还是当前按业务类型划分模块，复用这个接口就好，保留接口的可扩展性。

如果按模块划分的话，未来如果其他场景比如一键贴现接入刷脸的话，不用再搞一套新的接口，只需要新增枚举，然后复用刷脸通过流程接口，实现一键贴现刷脸的差异化即可。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

4.接口考虑是否需要防重处理

如果前端重复请求，你的逻辑如何处理？是不是考虑接口去重处理。

当然，如果是查询类的请求，其实不用防重。如果是更新修改类的话，尤其金融转账类的，就要过滤重复请求了。简单点，你可以使用Redis防重复请求，同样的请求方，一定时间间隔内的相同请求，考虑是否过滤。当然，转账类接口，并发不高的话，推荐使用数据库防重表，以唯一流水号作为主键或者唯一索引。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

5. 重点接口，考虑线程池隔离。

一些登陆、转账交易、下单等重要接口，考虑线程池隔离哈。如果你所有业务都共用一个线程池，有些业务出bug导致线程池阻塞打满的话，那就杯具了，所有业务都影响了。因此进行线程池隔离，重要业务分配多一点的核心线程，就更好保护重要业务。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

6. 调用第三方接口要考虑异常和超时处理

如果你调用第三方接口，或者分布式远程服务的的话，需要考虑：

• 异常处理

比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败还是告警处理。

• 接口超时

没法预估对方接口一般多久返回，一般设置个超时断开时间，以保护你的接口。之前见过一个生产问题，就是http调用不设置超时时间，最后响应方进程假死，请求一直占着线程不释放，拖垮线程池。

• 重试次数

你的接口调失败，需不需要重试？重试几次