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

Question

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

Answer 1

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

Answer 2

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