36 个接口设计锦囊，马住！
作为后端开发，不管是什么语言，Java、Go还是C++，其背后的后端思想都是类似的。后端开发工程师，主要工作就是：如何把一个接口设计好。所以，今天就给大家介绍，设计好接口的36个锦囊。

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

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

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

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

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

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

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

重试次数
你的接口调失败，需不需要重试试几次要站在业务上角度思考这个问题

7. 接口实现考虑熔断和降级

当前互联 系统一般都是分布式部署的。而分布式系统中经常会出现某个基础服务不可用，最终导致整个系统不可用的情况, 这种现象被称为服务雪崩效应。

比如分布式调用链路A->B->C…，下图所示：

不是所有的接口都适合设计为同步接口。比如你要做一个转账的功能，如果你是单笔的转账，你是可以把接口设计同步。用户发起转账时，客户端在静静等待转账结果就好。如果你是批量转账，一个批次一千笔，甚至一万笔的，你则可以把接口设计为异步。就是用户发起批量转账时，持久化成功就先返回受理成功。然后用户隔十分钟或者十五分钟等再来查转账结果就好。又或者，批量转账成功后，再回调上游系统。

如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。这种场景是可以改为并行调用的。也就是说查用户信息、查banner信息、查弹窗信息，可以同时发起。

21.接口状态和错误需要统一明确

提供必要的接口调用状态信息。比如你的一个转账接口调用是成功、失败、处理中还是受理成功等，需要明确告诉客户端。如果接口失败，那么具体失败的原因是什么。这些必要的信息都必须要告诉给客户端，因此需要定义明确的错误码和对应的描述。同时，尽量对 错信息封装一下，不要把后端的异常信息完全抛出到客户端。