接口设计原则
原则一：必须符合Restful，统一返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。
原则二： 命名必须规范、优雅。
原则三：单一性。
单一性是指接口要做的事情应该是一个比较单一的事情，比如登陆接口，登陆完成应该只是返回登陆成功以后一些用户信息即可，但很多人为了减少接口交互，返回一大堆额外的数据。
比如有人设计一个用户列表接口，接口他返回每一条数据都是包含用户了一大堆跟另外无关的数据，结果一问，原来其他无关的数据是他下一步想要获取的，想达成数据的懒加载。
原则四：可扩展。
接口扩展性，是指设计接口的时候多想想多种情况，多考虑各个方面，其实我觉得单独将扩展性放在这里也是不妥的，感觉说的跟单一性有点相反的意思，其实这个不是这个意思。
这边的扩展性是指我们的接口充分考虑客户端，想想他们是如何调用的，他要怎样使用我的代码，他会如何扩展我的代码，不要把过多的工作写在你的接口里面，而应该把更多的主动权交给客户程序员。
如获取不同的列表数据接口，我们不可能将每个列表都写成一个接口。 还有一点，我这里特别想指出来的是很多开发人员为了省事（姑且只能这么理解），将接口设计当成只是 app 页面展示。
这些人将一个页面展示就用一个接口实现，而不考虑这些数据是不是属于不同的模块、是不是属于不同的展示范畴、结果下次视觉一改，整个接口又得重写，不能复用。
原则五：必须有文档。
良好的接口设计，离不开清晰的接口文档表述。文档表述一定要足够详细
原则六：产品心。
为什么我说要有产品心？因为我觉得很多人忽略了这一点。我来说一下假如开发一个app，如果一开始连个交互文档给你都没有的话，你怎么设计接口？
所以我觉得作为一个服务端后台开发人员应该要有产品心，特别是对于交互文档应该好好理解，因为这些都会对我们的接口设计有很大的影响。
我在设计接口的时候就很常发现很多交互文档根本就走不通，产品没有考虑到位，交互文档缺失，这时候作为一个开发要主动推动，完善。
原则七：第三方服务接口数据能缓存就缓存。
原则八：第三方服务需要做降级。
原则九：建议消除单点。
原则十：接口粒度要小。
原则十一：客户端能处理的逻辑就不要给服务端处理，减少服务端压力。
原则十二：资源预加载。
原则十三：不要过度设计。
原则十四：缓存尽量不要穿透。
原则十五：接口能缓存就缓存。
原则十六：思辨大于执行
接口设计需要考虑哪些方面？ add 我的经验
- 接口的命名。 —— restful命名规范，都要是名词，见名知意
- 请求参数。 ——请求参数设置，要考虑接口扩展性、考虑接口的粒度。
- 支持的协议。 —— 明确协议类型
- TPS、并发数、响应时长。 —— 从接口颗粒度较小出发，考虑分布式缓存等。
- 数据存储。DB选型、缓存选型。 —— db考虑是否要分库分表， 采用DB+分布式缓存模式。
- 是否需要依赖于第三方。 —— 第三方接口数据是否可以缓存并使用，服务降级
- 接口是否拆分。 —— 接口颗粒度要小，横向、纵向的拆分。
- 接口是否通用、有扩展性。—— 考虑适配性
- 接口是否需要幂等。 —— 通俗的意思就是防止重复提交。 前端交换上设计防止重复提交，后端根据请求中某个特征字段，缓存并判断是否已经存在。
9.1.同步锁（单线程，集群可能会失效）
9.2.分布式锁如redis（实现复杂）
9.3.业务字段加唯一约束（简单）
9.4.令牌表+唯一约束（简单推荐）
9.5.mysql的insert ignore或者on duplicate key update（简单）
9.6.共享锁+普通索引（简单）
9.7.利用MQ或者Redis扩展（排队）
9.8. 其他方案如多版本控制MVCC 乐观锁 悲观锁 状态机等。。。
10. 防刷。 —— 会话的校验及有效时间，令牌表+唯一约束是不是就可以
11. 接口限流、降级。—— 配置接口最大tps ，熔断降级
12. 负载均衡器支持。 —— 借助nginx
13. 如何部署，是否存在单点。 —— 去单点，集群部署。高可用，还有灾备。
14. 是否需要服务治理。 —— 服务治理可以控制到单个API上下线。
15. 接口是否资源包、预加载还是内置。 ——静态资源缓存， h5 hybird模式，还有nginx缓存静态资源。
但是接口要对请求字段进行检查，针对数据库中肯定不存在的条件字段，直接返回，而不是调用后端查询，导致缓存穿透。
Redis缓存穿透、缓存雪崩和缓存击穿。
缓存穿透，是指查询一个数据库一定不存在的数据。
17. 是否需要白名单。
