http/2 多路复用对 REST API 设计的影响：是不是有了 http/2 以后，本来应该合并的请求都可以拆开了？

[akinoniku]

用获取 V2EX 上一个帖子的 API 来做例子：

http 1 ： API 应该返回一个大 object ，包含 title, description 以及全部 reply body 和 profile body 。

http/2 ： API 可以返回一个相对比较小的 object, 包含 title, description 以及 reply 和 profile 的 id list 。再根据这两个 id list 来进行（可能两百来次的）的 fetch 。

---

考虑到后者可以在前端缓存 profile ，那是不是意味着拆解 REST API 是更合理的方案呢？

[hxsf]

你家 db 要炸
明明一次 db 操作可以拿到所有请求，你非要一个个拿。。。。

考虑后端实现的情况下，拆分无依赖关系的数据是可以的。

比如文章内容和文章所有回复，本来就是要两次 db 操作。

[akinoniku]

@hxsf 一个一个拿也不用每次走 db ，而且 cache 策略还比较好写

[hxsf]

@akinoniku 每次走 cache ， http/2 省下来的时间，和花在频繁读 Cache 的时间

[hxsf]

@akinoniku 我的观点是不要为了 使用 http/2 的特性而使用
综合考虑，本来后端为了减少 http/1 时期请求次数，而合并的接口，可以拆开来提高效率和维护性。

举例如：
首页要加载 10 个模块的信息，没 http/2 之前，是后端一次性传给前端的。
上 http/2 后，可以分开了。

[akinoniku]

@hxsf 长失效时间和短失效时间的数据也可以分开交到前端了。

对于我来说最有用的应该是把某用户特定的数据从公共 API 分离，比如『当前用户是否对某楼层点过赞』，这样缓存效率会提高很多，但同时也增加了相当于楼层数的请求

[takatost]

@hxsf 考虑到每个请求都要走同样的中间件，简单的项目还好，复杂的项目中应该尽可能的避免

[lhbc]

一次请求，和阻塞型的多次请求(楼主你的场景是后续的请求依赖上一个请求的结果)，速度肯定是后者慢很多。

[akinoniku]

@lhbc 但第一个请求变快了

[hxsf]

@takatost 恩，所以说综合考虑嘛。比如拆分后，一些不同时效的 可以被 cdn 或者 页面级缓存 根据不同策略缓存。

反正要考虑的有点多。。

[oott123]

不明白，为啥要一个一个取呢？
楼主这个 case 下，明明可以传一个 idlist 给后端，然后批量取嘛……

[xinyewdz]

@hxsf 和 db 爆炸没有关系吧（ db 有连接池）。多花的时间是 http 请求的时间。而且对于中大型项目来说，每次 sql 要尽量的简单，对简单 sql 的结果缓存更有效率，缓存不容易失效。

[oott123]

API 可以返回一个相对比较小的 object, 包含 title, description 以及 reply 和 profile 的 id list 。再根据这两个 id list 来进行（两个批量的） fetch 。

[akinoniku]

@oott123 bulk fetch 并不 RESTful...

[oott123]

@akinoniku 🌚好吧，不是很懂你们 RESTful 。

[akinoniku]

@xinyewdz 所以你觉得分离请求比较讲道理？

[qwer1234asdf]

@hxsf 客户端喜欢大包大揽的最好是一个接口返回所有数据，后端喜欢拆开，逐个返回。。。最近遇到的。。

[lhbc]

@akinoniku 实际上，单个请求， HTTP/2 和 HTTPS/1.1 并没有区别。

[akinoniku]

@lhbc 但有更高的缓存命中率和更小的 payload

[lhbc]

@akinoniku 缓存这个只和程序设计有关，和协议无关
至于传输，看你的数据大小，比如现在的数据是 10K ，传输就是几个包，和单个数据包没啥区别

如果网络较差，多一次阻塞请求就是多两个 TTL

[msg7086]

其实主要考虑的应该是 roundtrip 的开销吧。和 db 也好 cache 也好都关系不大。
http/2 的话大概也要看你 web server 对协议高级特性的支持程度？