来讨论下你们的api是怎么写的？

Question

我的理解
我写了快几年的api了，一直都遵循着，一个api接口完成一个事情的规则
我可能还是更多的倾向于一个接口完成一个事情！
我的困惑
现在的有些app首页内容量很大，有的人主张首页一个api返回所有数据，因为他说要减少请求的次数，以减少耗电等
看一本关于优化的书籍的时候，也的却有提到减少网络请求的优化方式
基于1的困惑，我的理解假如有一张表，或者数据产生堵塞，会影响整个app首页的加载，会不会更不好。
我想请教或者讨论的
你们的项目，你的接口遵循的是什么规则
首页的问题，你们是如何处理的
对于接口分拆和减少网络请求你们是怎么权衡的

Answer 1

尽量遵循RESTful，但是也要和实际业务需求结合，灵活应变。首页一般是聚合页，数据来源较多。通常：按功能分，按缓存分。也不会全部放在一个接口里。静态内容全部走CDN，减少PHP服务器的压力，一个页面调用的API接口最多三个。

Answer 2

脱离需求谈规范，都是不对的。正所谓分久必合，合久必分：在之前，前端的并发能力有限，减少请求次数是性能优化的一个重要手段，那你只能妥协。现在，你可以在架构上尝试解决，比如http2的合并请求，又或者用api网关合并，那就能同时满足后端保持单一职责，前端减少请求。总体的趋势，看起来是“分”的越来越彻底，比如从微服务到FaSS，但那只是把“合”的部分放在“平台”来解决