前言
大家好,作为后端开发,不管是什么语言,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调用不设置超时时间,最后响应方进程假死,请求一直占着线程不释放,拖垮线程池。
-
重试次数
你的接口调失败,需不需要重试?重试几次