V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
akinoniku
V2EX  ›  问与答

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

  •  2
     
  •   akinoniku · 2016-10-19 06:53:00 +08:00 · 3395 次点击
    这是一个创建于 2736 天前的主题,其中的信息可能已经有所发展或是发生改变。

    用获取 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 是更合理的方案呢?

    22 条回复    2016-12-14 11:56:27 +08:00
    hxsf
        1
    hxsf  
       2016-10-19 08:48:47 +08:00 via Android
    你家 db 要炸
    明明一次 db 操作可以拿到所有请求,你非要一个个拿。。。。

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

    比如文章内容和文章所有回复,本来就是要两次 db 操作。
    akinoniku
        2
    akinoniku  
    OP
       2016-10-19 08:58:06 +08:00
    @hxsf 一个一个拿也不用每次走 db ,而且 cache 策略还比较好写
    hxsf
        3
    hxsf  
       2016-10-19 09:00:12 +08:00
    @akinoniku 每次走 cache , http/2 省下来的时间,和花在频繁读 Cache 的时间
    hxsf
        4
    hxsf  
       2016-10-19 09:03:24 +08:00
    @akinoniku 我的观点是不要为了 使用 http/2 的特性而使用
    综合考虑,本来后端为了减少 http/1 时期请求次数,而合并的接口,可以拆开来提高效率和维护性。

    举例如:
    首页要加载 10 个模块的信息,没 http/2 之前,是后端一次性传给前端的。
    上 http/2 后,可以分开了。
    akinoniku
        5
    akinoniku  
    OP
       2016-10-19 09:16:01 +08:00
    @hxsf 长失效时间和短失效时间的数据也可以分开交到前端了。

    对于我来说最有用的应该是把某用户特定的数据从公共 API 分离,比如『当前用户是否对某楼层点过赞』,这样缓存效率会提高很多,但同时也增加了相当于楼层数的请求
    takatost
        6
    takatost  
       2016-10-19 09:16:39 +08:00
    @hxsf 考虑到每个请求都要走同样的中间件,简单的项目还好,复杂的项目中应该尽可能的避免
    lhbc
        7
    lhbc  
       2016-10-19 09:27:08 +08:00 via iPhone
    一次请求,和阻塞型的多次请求(楼主你的场景是后续的请求依赖上一个请求的结果),速度肯定是后者慢很多。
    akinoniku
        8
    akinoniku  
    OP
       2016-10-19 09:38:15 +08:00
    @lhbc 但第一个请求变快了
    hxsf
        9
    hxsf  
       2016-10-19 09:40:58 +08:00
    @takatost 恩,所以说综合考虑嘛。比如拆分后,一些不同时效的 可以被 cdn 或者 页面级缓存 根据不同策略缓存。

    反正要考虑的有点多。。
    oott123
        10
    oott123  
       2016-10-19 10:00:50 +08:00
    不明白,为啥要一个一个取呢?
    楼主这个 case 下,明明可以传一个 idlist 给后端,然后批量取嘛……
    xinyewdz
        11
    xinyewdz  
       2016-10-19 10:01:16 +08:00
    @hxsf 和 db 爆炸没有关系吧( db 有连接池)。多花的时间是 http 请求的时间。而且对于中大型项目来说,每次 sql 要尽量的简单,对简单 sql 的结果缓存更有效率,缓存不容易失效。
    oott123
        12
    oott123  
       2016-10-19 10:01:23 +08:00
    API 可以返回一个相对比较小的 object, 包含 title, description 以及 reply 和 profile 的 id list 。再根据这两个 id list 来进行(两个批量的) fetch 。
    akinoniku
        13
    akinoniku  
    OP
       2016-10-19 10:19:00 +08:00
    @oott123 bulk fetch 并不 RESTful...
    oott123
        14
    oott123  
       2016-10-19 10:20:13 +08:00
    @akinoniku 🌚好吧,不是很懂你们 RESTful 。
    akinoniku
        15
    akinoniku  
    OP
       2016-10-19 10:25:27 +08:00
    @xinyewdz 所以你觉得分离请求比较讲道理?
    qwer1234asdf
        16
    qwer1234asdf  
       2016-10-19 11:29:29 +08:00
    @hxsf 客户端喜欢大包大揽的最好是一个接口返回所有数据,后端喜欢拆开,逐个返回。。。最近遇到的。。
    lhbc
        17
    lhbc  
       2016-10-19 11:32:44 +08:00
    @akinoniku 实际上,单个请求, HTTP/2 和 HTTPS/1.1 并没有区别。
    akinoniku
        18
    akinoniku  
    OP
       2016-10-19 11:45:21 +08:00
    @lhbc 但有更高的缓存命中率和更小的 payload
    lhbc
        19
    lhbc  
       2016-10-19 12:02:09 +08:00
    @akinoniku 缓存这个只和程序设计有关,和协议无关
    至于传输,看你的数据大小,比如现在的数据是 10K ,传输就是几个包,和单个数据包没啥区别

    如果网络较差,多一次阻塞请求就是多两个 TTL
    msg7086
        20
    msg7086  
       2016-10-19 12:44:04 +08:00
    其实主要考虑的应该是 roundtrip 的开销吧。和 db 也好 cache 也好都关系不大。
    http/2 的话大概也要看你 web server 对协议高级特性的支持程度?
    shyling
        21
    shyling  
       2016-10-19 12:51:53 +08:00
    和 http/2 关系不大吧
    iugo
        22
    iugo  
       2016-12-14 11:56:27 +08:00
    本来 "应该拆开但迫不得已合并的" 请求都可以拆开了.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4143 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 66ms · UTC 10:19 · PVG 18:19 · LAX 03:19 · JFK 06:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.