用获取 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 是更合理的方案呢?
1
hxsf 2016-10-19 08:48:47 +08:00 via Android
你家 db 要炸
明明一次 db 操作可以拿到所有请求,你非要一个个拿。。。。 考虑后端实现的情况下,拆分无依赖关系的数据是可以的。 比如文章内容和文章所有回复,本来就是要两次 db 操作。 |
4
hxsf 2016-10-19 09:03:24 +08:00
@akinoniku 我的观点是不要为了 使用 http/2 的特性而使用
综合考虑,本来后端为了减少 http/1 时期请求次数,而合并的接口,可以拆开来提高效率和维护性。 举例如: 首页要加载 10 个模块的信息,没 http/2 之前,是后端一次性传给前端的。 上 http/2 后,可以分开了。 |
5
akinoniku OP @hxsf 长失效时间和短失效时间的数据也可以分开交到前端了。
对于我来说最有用的应该是把某用户特定的数据从公共 API 分离,比如『当前用户是否对某楼层点过赞』,这样缓存效率会提高很多,但同时也增加了相当于楼层数的请求 |
7
lhbc 2016-10-19 09:27:08 +08:00 via iPhone
一次请求,和阻塞型的多次请求(楼主你的场景是后续的请求依赖上一个请求的结果),速度肯定是后者慢很多。
|
9
hxsf 2016-10-19 09:40:58 +08:00
|
10
oott123 2016-10-19 10:00:50 +08:00
不明白,为啥要一个一个取呢?
楼主这个 case 下,明明可以传一个 idlist 给后端,然后批量取嘛…… |
11
xinyewdz 2016-10-19 10:01:16 +08:00
@hxsf 和 db 爆炸没有关系吧( db 有连接池)。多花的时间是 http 请求的时间。而且对于中大型项目来说,每次 sql 要尽量的简单,对简单 sql 的结果缓存更有效率,缓存不容易失效。
|
12
oott123 2016-10-19 10:01:23 +08:00
API 可以返回一个相对比较小的 object, 包含 title, description 以及 reply 和 profile 的 id list 。再根据这两个 id list 来进行(两个批量的) fetch 。
|
16
qwer1234asdf 2016-10-19 11:29:29 +08:00
@hxsf 客户端喜欢大包大揽的最好是一个接口返回所有数据,后端喜欢拆开,逐个返回。。。最近遇到的。。
|
19
lhbc 2016-10-19 12:02:09 +08:00
|
20
msg7086 2016-10-19 12:44:04 +08:00
其实主要考虑的应该是 roundtrip 的开销吧。和 db 也好 cache 也好都关系不大。
http/2 的话大概也要看你 web server 对协议高级特性的支持程度? |
21
shyling 2016-10-19 12:51:53 +08:00
和 http/2 关系不大吧
|
22
iugo 2016-12-14 11:56:27 +08:00
本来 "应该拆开但迫不得已合并的" 请求都可以拆开了.
|