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

Question

我的理解

1. 我写了快几年的api了，一直都遵循着，一个api接口完成一个事情的规则
2. 我可能还是更多的倾向于一个接口完成一个事情！

我的困惑

1. 现在的有些app首页内容量很大，有的人主张首页一个api返回所有数据，因为他说要减少请求的次数，以减少耗电等
2. 看一本关于优化的书籍的时候，也的却有提到减少网络请求的优化方式
3. 基于1的困惑，我的理解假如有一张表，或者数据产生堵塞，会影响整个app首页的加载，会不会更不好。

我想请教或者讨论的

1. 你们的项目，你的接口遵循的是什么规则
2. 首页的问题，你们是如何处理的
3. 对于接口分拆和减少网络请求你们是怎么权衡的

Answer 1

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

Answer 2

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

Answer 3

接口原则的话，当然必须是以业务需要为核心前提，规则的话 RESTful 你可以区了解下 首页的话，看什么样的网站了，如果数据量不大那一次给完数据也行，数据量大的话我认为还是和前端同事商量下怎么去优化吧，有些东西能静态化的静态化，能缓存的缓存 分拆和减少 HTTP 请求这件事情还是那句话，根据自身的业务好好考虑那些请求可以合并，哪些又可以拆分，核心还是那句话，怎么权衡要看具体的业务场景的，技术脱离了业务场景就没意义了