接口设计需要考虑哪些方面
接口的命名。
请求参数。
支持的协议。
TPS、并发数、响应时长。
数据存储。DB选型、缓存选型。
是否需要依赖于第三方。
接口是否拆分。
接口是否需要幂等。
防刷。
0.接口限流、降级。
负载均衡器支持。
如何部署。
是否需要服务治理。
是否存在单点。
接口是否资源包、预加载还是内置。
是否需要本地缓存。
是否需要分布式缓存、缓存穿透怎么办。
是否需要白名单。
当我们设计接口，我们或多或少都会有上面列举的一些考虑，我们只有想的更多才能让让我们的接口更加完善，我个人觉得100%完美的接口是不存在，只有适合才是最重要。
接口设计原则
原则必须符合Restful，统一返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。
原则命名必须规范、优雅。
原则单一性。
单一性是指接口要做的事情应该是一个比较单一的事情，比如登陆接口，登陆完成应该只是返回登陆成功以后一些用户信息即可，但很多人为了减少接口交互，返回一大堆额外的数据。
比如有人设计一个用户列表接口，接口他返回每一条数据都是包含用户了一大堆跟另外无关的数据，结果一问，原来其他无关的数据是他下一步想要获取的，想达成数据的懒加载。
原则可扩展。
接口扩展性，是指设计接口的时候多想想多种情况，多考虑各个方面，其实我觉得单独将扩展性放在这里也是不妥的，感觉说的跟单一性有点相反的意思，其实这个不是这个意思。
这边的扩展性是指我们的接口充分考虑客户端，想想他们是如何调用的，他要怎样使用我的代码，他会如何扩展我的代码，不要把过多的工作写在你的接口里面，而应该把更多的主动权交给客户程序员。
如获取不同的列表数据接口，我们不可能将每个列表都写成一个接口。还有一点，我这里特别想指出来的是很多开发人员为了省事，将接口设计当成只是app页面展示。
这些人将一个页面展示就用一个接口实现，而不考虑这些数据是不是属于不同的模块、是不是属于不同的展示范畴、结果下次视觉一改，整个接口又得重写，不能复用。
原则必须有文档。
良好的接口设计，离不开清晰的接口文档表述。文档表述一定要足够详细
原则产品心。原则第三方服务接口数据能缓存就缓存。
原则第三方服务需要做降级。
原则建议消除单点。
原则接口粒度要小。
原则十客户端能处理的逻辑就不要给服务端处理，减少服务端压力。
原则十资源预加载。
原则十不要过度设计。
原则十缓存尽量不要穿透。
原则十接口能缓存就缓存。
原则十思辨大于执行高性能：如果我们发现这个接口tps和响应时间没有达到我们的要求怎么办。
A：数据存储方面：我们会想数据库有没有分库、分表、有没有做主从，有没有读写分离、字段是否有加索引、是否存在慢sql，数据库引擎是否选用合适、是不是用了事务；
其次我们会想到是不是引用了分布式缓存、缓存key大小是否合适，失效时间是否设置合理，会不会大量缓存穿透、有没有引入本地缓存。
B：业务方面：是否有大量的计算、能否异步处理。是否需要引入线程池或者MQ来异步处理任务。有没有必要将接口进行垂直拆分和水平拆分、将接口粒度变小。
C：其他方面：nginx层面做缓存、加机器、用ssd，资源放cdn，多机房部署、资源文件预加载。高可用：如何保证服务高可用，需要从几个维度来实现：
A：消除单点，基于高可用第二位。
B：能做集群的全部做集群。譬如Redis集群、mysql集群、MongoDB副本集。
C：能做读写分离的都做读写分离。
D：异地多机房部署，接入GSLB
E：必须有限流、降级机制。
F：监控。高可用的保证，基于第一位。
文章为作者独立观点，不代表 股票程序化软件自动交易接口观点
股民评论