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

有严格遵守 RESTful 范式的朋友吗?

  •  
  •   codeismylife · 2021-04-15 10:47:19 +08:00 · 1903 次点击
    这是一个创建于 1079 天前的主题,其中的信息可能已经有所发展或是发生改变。

    很多人,接口设计都是纯 200,然后 BODY 类似:

    {
      "code":0,
      "message":"",
      "data":null
    

    URL 类似:

    /user?id=1
    

    这样。 刚开始我也试图遵守 RESTful 范式的,但是我身边很多人都喜欢包这么一层,然后什么请求都响应 200,我也就这么做了。 非常好奇为啥大家喜欢这么包一层,是因为业务复杂 http status 不够用才用 code 吗? 话说这种方案,我实在没想出来有啥大的优点呢……

    17 条回复    2021-04-16 13:44:33 +08:00
    mhycy
        1
    mhycy  
       2021-04-15 10:48:46 +08:00
    非 200 状态码可能会被浏览器 or 网关拦截
    kkkkkrua
        2
    kkkkkrua  
       2021-04-15 11:00:48 +08:00
    可以搞,但是不要照本宣科,有些复杂的场景 RESTful 也没办法表示其意思
    baiyi
        3
    baiyi  
       2021-04-15 11:00:55 +08:00   ❤️ 1
    RESTful 没有一个标准范式,只有各大厂商的实践规范,所以也谈不上遵守。

    在成功的响应中加 code 和 message 字段在我看在是无意义行为,只是为了方便调用者使用统一结构进行解析的偷懒行为。
    但 data 字段在某些情况是需要在在成功的响应中返回的,因为 oc 不支持解析数组形式的 json 数据...不知道现在是否支持了,除此之外也没有什么必要加 data 字段。

    至于 http status code 是否能够代表业务状态,在我看来是不能代表的,它最好只代表 http 请求的状态。因为在客户端提交请求的过程中,各个组件(代理、网关等)都是根据 http status code 来对请求进行处理。

    在响应错误时,如果有额外的 message 字段来对错误进行描述,或者增加 code 字段来代表某一类 message,这都是业务需要,与 RESTful 无关。
    abersheeran
        4
    abersheeran  
       2021-04-15 11:16:20 +08:00
    可能是因为以前的项目都是这么封装的,有许多现成的代码。没有影响业务的情况下,就不改了。
    MiniGhost
        5
    MiniGhost  
       2021-04-15 11:31:04 +08:00   ❤️ 1
    非 200 被拦截这一点,现在满大街都是 HTTPS 了,已经没有这个问题了

    清一色都返回 200,问题是比较大的

    之前帮前端 Debug 就遇到过,打开一个页面发了十几个 request,清一色返回都是 200,但是页面提示报错,还得一个个请求点进去看 response 才知道具体是哪个接口的问题。

    然后还有问题就是,如果清一色都是反 200,在一些日志收集服务上,看大盘统计反馈不出业务的服务质量,因为都是 200 状态码。如果改统计规则,改成读取 body 内的 code 来做质量统计,json 又做不到强制格式约束,做不到 100%的格式约束。
    IvanLi127
        7
    IvanLi127  
       2021-04-15 12:40:40 +08:00 via Android
    自己的项目就严格遵守,公司的只能跟着大家的写法写了。遵守起来是可行的,不过有些地方不变通,其实也不太好。
    响应包一层就很无语了,异常处理流程能是正常流程一样么,包一层也做不到复用,还浪费
    wangkun025
        8
    wangkun025  
       2021-04-15 12:45:24 +08:00
    用的是 Ruby on Rails,写 API 的时候,尽量使用状态码。但有的同事喜欢在 body 里写状态码,然后全部用 post 。
    lsdvincent
        9
    lsdvincent  
       2021-04-15 13:29:49 +08:00
    还真有,但是有时候会被说有点繁琐,太严格了
    timethinker
        10
    timethinker  
       2021-04-15 13:52:21 +08:00   ❤️ 2
    的确是有很多公司用统一的包装体来返回所有的数据,我个人认为这是没有必要的。
    首先,在成功的情况下,code 和 message 是没有意义的,前端也只会取里面的 body 字段。
    其次,在失败的情况下,body 字段一般都为 null 。
    就先前面几位说的,如果在失败的情况下不使用 HTTP 4XX 状态码,而全部使用 200,对外部的监控 /采集系统来说也确实不太标准。
    所以这个包装体在成功或者失败的情况下都存在冗余字段。
    我们目前对于成功的请求( 2XX ),只返回数据本身,不同的接口直接返回不同的数据。
    失败的情况下才会返回统一的错误数据结构,比如 code 、message 。
    FrankFang128
        11
    FrankFang128  
       2021-04-15 14:22:54 +08:00
    他们在老一辈的恐吓放弃 status code,
    现在又来恐吓你
    vibbow
        12
    vibbow  
       2021-04-15 17:02:17 +08:00
    HTTP status code -> Load Balancer 是否成功访问到了后端服务器
    Body status code -> 应用层是否处理成功
    yyzcl
        13
    yyzcl  
       2021-04-15 17:04:44 +08:00 via iPhone
    自己的项目遵守。公司的随大流
    vibbow
        14
    vibbow  
       2021-04-15 17:04:56 +08:00
    其次就是应用层可以定义较为复杂的错误代码信息

    比如说 AABBCC 这样六位数的错误代码,可以将错误明确指向到 AA 系统,BB 模块,CC 错误
    wakzz
        15
    wakzz  
       2021-04-15 17:05:12 +08:00
    RESTful 范式对于简单的场景还行,业务错误码稍微复杂点,就捉襟见肘了。
    cxe2v
        16
    cxe2v  
       2021-04-15 17:10:16 +08:00
    一个实际问题,RESTful 如何支持复杂的业务返回码?楼主有成熟可靠的设计方案吗?
    codeismylife
        17
    codeismylife  
    OP
       2021-04-16 13:44:33 +08:00
    @cxe2v 我其实也不是严格遵守 RESTful 的,当业务较为复杂的时候,我会在 4XX 和 5XX 情况下,返回值里塞 CODE 字段,里面就是错误业务类错误码。200 情况下不再进行包装。业务不复杂的时候,严格遵守 RESTful 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5574 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 40ms · UTC 06:36 · PVG 14:36 · LAX 23:36 · JFK 02:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.