V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Zach369
V2EX  ›  程序员

api 接口 http 响应码问题?

  •  
  •   Zach369 · 2019-11-11 11:12:30 +08:00 · 8219 次点击
    这是一个创建于 1821 天前的主题,其中的信息可能已经有所发展或是发生改变。

    2018 年 新项目 开始使用 restful 风格接口. 所有的返回 遵循 HTTP 响应码. 结果 很不理想,不管是 web 还是客户端,亦或者安卓和 ios. 都很反对这种开发模式. 但是楼主还是坚持了下来.

    目前又有一个跟外包配合的项目. 外包那边提出 所有的接口 必须是 200.

    返回格式必须是:

    {
        "code": 0,        //0 位正常,其他则为异常.
        "result": "",
        "msg": "报错信息"
    }
    
    

    想问下 各位大佬现在是怎么使用的那?

    70 条回复    2019-11-13 09:45:16 +08:00
    wunonglin
        1
    wunonglin  
       2019-11-11 11:16:35 +08:00
    月经贴
    lcy630409
        2
    lcy630409  
       2019-11-11 11:18:28 +08:00
    - - ,各位来吧
    我赞同 code 等于状态
    大概是用 thinkphp 习惯了
    pelloz
        3
    pelloz  
       2019-11-11 11:18:42 +08:00
    不要教条,哪种方便用哪种,混着用最方便
    TomVista
        4
    TomVista  
       2019-11-11 11:19:06 +08:00
    这个无所谓,写好文档,定义好格式,就够了.
    fengpan567
        5
    fengpan567  
       2019-11-11 11:19:48 +08:00
    格式没问题,三部分都有。但是错误码还得根据自己的业务来,我自己设计接口也不会把 200 当成成功返回值。
    lcy630409
        6
    lcy630409  
       2019-11-11 11:20:01 +08:00   ❤️ 2
    之前和一个 windows 软件开发的同事对接过,
    他们也是喜欢 code=1 是错误,0 是正常,
    我就喜欢 code=1 正常 0 错误.....
    Raymon111111
        7
    Raymon111111  
       2019-11-11 11:22:46 +08:00
    0 表明正常, 其它表示异常.

    实现的又不是 http 协议, 用 http 协议的规范是有点奇怪的.
    zxcslove
        8
    zxcslove  
       2019-11-11 11:23:00 +08:00
    @lcy630409 估计思路是这样的:前一种只有 1 和 0,后一种 0 是正常,异常则有很多种。
    Smilencer
        9
    Smilencer  
       2019-11-11 11:23:55 +08:00 via iPhone
    随意
    zhuweiyou
        10
    zhuweiyou  
       2019-11-11 11:26:40 +08:00
    因为这个 code 你要理解成 error code,所以 0 是正常,才是对的。
    zqguo
        11
    zqguo  
       2019-11-11 11:28:01 +08:00
    问题不大啊,规范好就行了,没啥纠结的。
    HangoX
        12
    HangoX  
       2019-11-11 11:28:20 +08:00
    我不明白的地方是,如果用 http 状态码表示的话,反正我都要解析内容,那我干嘛还要管 http 状态码?
    baiyi
        13
    baiyi  
       2019-11-11 11:31:07 +08:00   ❤️ 2
    快成周经贴了

    我支持响应部分 HTTP status code,成功时 "code:0" 完全没有必要,直接返回数据
    wangkun025
        14
    wangkun025  
       2019-11-11 11:31:55 +08:00
    我用状态码
    Hopetree
        15
    Hopetree  
       2019-11-11 11:32:19 +08:00
    他们要所有接口都返回 200 应该是考虑的前后端分离,现在前后端分离的话,按照这种返回格式给前端去判断其实也挺好的,所以说两种方式没有哪种更好,看需求,怎么好用怎么来呗
    wangyzj
        16
    wangyzj  
       2019-11-11 11:34:00 +08:00
    0 位正常,其他则为异常.
    我现在就是这样
    dallaslu
        17
    dallaslu  
       2019-11-11 11:57:32 +08:00
    把整个 HTTP Header 都在 JSON 里写一遍,爱用哪个用哪个。
    rogwan
        18
    rogwan  
       2019-11-11 11:57:37 +08:00 via iPhone
    code = 0 是有 sub_code 的含义,用于标注业务状态
    kwanzaa
        19
    kwanzaa  
       2019-11-11 12:02:08 +08:00
    没问题,但是要写好文档。400/500/等异常处理要很明确协定。

    抛个 http code 就不管的人都是憨憨。
    riverluoo
        20
    riverluoo  
       2019-11-11 12:46:21 +08:00
    双方约定好 就好了
    chanchan
        21
    chanchan  
       2019-11-11 12:49:14 +08:00
    反正我觉得 http status 不是用来描述业务的
    binux
        22
    binux  
       2019-11-11 12:53:28 +08:00 via Android   ❤️ 4
    我现在觉得国内这个状况就是能力问题。
    大部分人连 HTTP 状态码是什么,有哪些都搞不明白,你让他们处理非 200 自然是不行的。

    无论在英国还是美国,和别的开发者交流,按照语义返回状态码都是理所应当的。如果你说统统返回 200,他们还会问为什么。
    yulitian888
        23
    yulitian888  
       2019-11-11 13:02:51 +08:00   ❤️ 4
    这个视情况而定的。
    如果终端是服务器调用的话,两者皆可,自行约定就行。但是如果终端是浏览器的话,你用 http 的 4xx,5xx 返回,信不信有浏览器厂家给你夹带私货、偷梁换柱?比如某些国产套壳浏览器遇到 404,会重定向到浏览器自带的 404,页面里面还给顺手加点广告。
    IceBay
        24
    IceBay  
       2019-11-11 13:06:07 +08:00
    @yulitian888 #23 application/json 也会这样吗?
    back0893
        25
    back0893  
       2019-11-11 13:07:46 +08:00
    战起来
    上次战了几百贴
    reus
        26
    reus  
       2019-11-11 13:10:59 +08:00
    @binux 他们又没有被“智能路由”、“智能浏览器”劫持非 200 返回的历史……
    whp1473
        27
    whp1473  
       2019-11-11 13:25:51 +08:00
    最大问题是 Http 的 Code 码是 3** 4** 2**都是有规定含义的,浏览器表现也不同,用这个一些自定义的返回很难说明。前后去过的两家公司都是统一返回 200,内部状态码判断 msg 说明错误描述 value 返回值
    KuroNekoFan
        28
    KuroNekoFan  
       2019-11-11 13:31:13 +08:00 via iPhone
    随便吧,不正常的 status 和 data.code 都 reject 掉就完事了
    warcraft1236
        29
    warcraft1236  
       2019-11-11 13:32:06 +08:00   ❤️ 1
    @binux 3xx 4xx 5xx 是给 nginx 返回的,服务端的程序只要能返回数据,就说明 http 200,错误都是服务端程序自己定义的错误,很多都是业务上的错误。比如自己写的业务代码也反 500,那就不够直观的判断是 nginx 返回 500 还是程序返回 500。所以要求程序全都反 200 的 http status,其他的东西都放到 response body 里边自己去判断
    Lonersun
        30
    Lonersun  
       2019-11-11 13:44:23 +08:00   ❤️ 1
    我们是这样搞得:
    200 定义请求成功,
    400 定义业务异常,再进行业务细分,返回具体的错误码及错误信息
    500 定义服务异常,
    binux
        31
    binux  
       2019-11-11 13:48:57 +08:00 via Android
    @warcraft1236 #29 你连判断 Nginx 还是程序的错误都做不到吗?
    jonahtan
        32
    jonahtan  
       2019-11-11 13:58:14 +08:00
    200 查询成功(GET)
    201 操作成功(POST/PUT/DELETE)
    400 业务处理异常
    401 鉴权失败
    404not found
    500 服务处理异常

    具体的业务错误代码放在 response 的 code 里面。
    realpg
        33
    realpg  
       2019-11-11 13:58:25 +08:00
    习惯 1 0 和负数表示法

    不定义为 code 因为用 code 隐含的意思是 0 正常

    定义为 status

    1 为通常状态正常
    0 为非业务逻辑状态非正常
    负数为各种针对每个业务的错误代码
    dcty
        34
    dcty  
       2019-11-11 14:02:05 +08:00
    谁给钱谁说了算
    warcraft1236
        35
    warcraft1236  
       2019-11-11 14:03:31 +08:00
    @binux 注意,是方便两个字,要的是快速。你要是抬杠那就没意思了。写代码还能用记事本呢,还不需要任何代码提示呢
    warcraft1236
        36
    warcraft1236  
       2019-11-11 14:04:55 +08:00
    @binux 另外,为什么国外的程序员觉得直接用 http status,就代表是对的?
    fkdog
        37
    fkdog  
       2019-11-11 14:11:31 +08:00   ❤️ 2
    我来总结一下,

    整天嘴上挂着 restful 的基本都是那种刚毕业没几年充满了理想主义,然后在小公司混迹的,工作量太少吃饱了没事干整天把 restful 当成圣经一样供奉着。

    小公司增删改查没多大复杂业务的,妄想几个 http code 来解决业务需求,脑子烧坏了把。
    bfqymmt
        38
    bfqymmt  
       2019-11-11 14:20:59 +08:00
    @back0893 有上次的大战贴吗?学习一下
    telami
        39
    telami  
       2019-11-11 16:16:11 +08:00   ❤️ 1
    非常认同 rest 中关于 url 是资源定位符的概念,增删改查对应 post、delete、put、get,但是返回 http 状态码简直就是灾难,联调时返回 404,已经无法辨认是不存在这个接口,还是不存在 [user/1] id 为 1 的人
    jabin88
        40
    jabin88  
       2019-11-11 16:27:24 +08:00   ❤️ 1
    遵循 HTTP 响应码 这样最好。我见过很多合作公司的文档都这样
    KyonLi
        41
    KyonLi  
       2019-11-11 16:45:16 +08:00   ❤️ 3
    caryqy
        42
    caryqy  
       2019-11-11 17:22:32 +08:00   ❤️ 1
    http code 那几个不够用啊

    文档写好就行,每个 code 对应的什么含义
    xuanbg
        43
    xuanbg  
       2019-11-11 17:31:09 +08:00
    这种封装结构其实是 OSI 模型分层思想的体现。http 协议在 OSI 模型中对应的是第 4、5、6 三层,webAPI 对应的是第 7 层。高层的应用当然不需要也不应该去干涉更低层的逻辑。
    xuanbg
        44
    xuanbg  
       2019-11-11 17:36:48 +08:00
    原教旨主义的 REST 实际上混淆了应用和数据传输,违反了分层的思想。导致了更高的耦合度和逻辑的复杂化,在我看来是不可取的。

    另外,搭车问一个问题:验证短信验证码的 url 该如何定义?该使用何种请求方法?
    yulitian888
        45
    yulitian888  
       2019-11-11 21:18:21 +08:00
    @IceBay 以前遇到的,但是没注意当时 Content-Type 是什么
    lihongjie0209
        46
    lihongjie0209  
       2019-11-11 21:53:03 +08:00   ❤️ 1
    随便在聚合数据上找了一个, 你用 http code 定义以下这些错误代码。https://www.juhe.cn/docs/api/id/54

    还有, 一个协议层的 code 居然会和业务关联, 如果以后需要使用 tcp 模式的 rpc 调用, 你到哪里去找 http code ?
    gamexg
        47
    gamexg  
       2019-11-11 22:30:12 +08:00
    @lcy630409 #6 0 为正常的好处是 其他值可以作为错误代码提供更详细的错误信息。

    另外 http 的那几个错误代码根本不够用。
    Tokin
        48
    Tokin  
       2019-11-11 23:06:47 +08:00
    @gamexg 应该是用 http 状态码归类吧,具体错误和错误代码还是要在主体中返回。
    我用了一段时间 http 状态码,一直难以适应。
    ryougifujino
        49
    ryougifujino  
       2019-11-11 23:58:53 +08:00   ❤️ 2
    看了之前那个讨论贴,总结一下个人感觉最好的:所有 http code 还是按正常语义返回。正常情况下直接返回数据,不包一层。在有错误的情况下,如果有必要对话,在 response body 里面定义更详细错误码。
    oneisall8955
        50
    oneisall8955  
       2019-11-12 00:10:16 +08:00 via Android
    我又看了上次 300+回帖打架起来的帖子,继续战起来战起来🤺
    ggicci
        51
    ggicci  
       2019-11-12 01:25:02 +08:00
    不要问,问就是 RESTful 和 GraphQL
    nvkou
        52
    nvkou  
       2019-11-12 01:59:33 +08:00 via Android   ❤️ 1
    @fkdog 几个?没说不准自定义啊。code 250:查询成功,但服务器闹脾气了,回滚了操作。
    nvkou
        53
    nvkou  
       2019-11-12 02:01:31 +08:00 via Android
    @lihongjie0209 教条主义:restful 只用 http ( s )
    whileFalse
        54
    whileFalse  
       2019-11-12 07:06:39 +08:00 via iPhone   ❤️ 1
    body 按 JSON 风格,code=0 为正常。
    HTTP status code 按语义。
    协议走 HTTPS。以前有的运营商会劫持非 200 返回,现在不清楚。
    API 使用者只要按 JSON 解码并查看 code 即可。如果 JSON 解码失败说明服务器不正常。
    HTTP status code 用来进行具体业务无关的宏观统计。比如监控 5xx 的发生率等等。status code 没必要分的特别细致。
    alphatoad
        55
    alphatoad  
       2019-11-12 07:49:27 +08:00
    GraphQL 天下第一
    zr8657
        56
    zr8657  
       2019-11-12 07:50:46 +08:00 via Android
    月经贴别战了,甲方说啥干啥呗,混口饭吃得了,有那功夫纠结不如去干点自己喜欢的事
    vultr
        57
    vultr  
       2019-11-12 08:31:19 +08:00
    @Lonersun #30 我们也是这样子处理的。
    killerv
        58
    killerv  
       2019-11-12 09:36:38 +08:00
    http 状态码按照实际业务来返回,不要全部都是 200,不过 body 中还是要指明 errCode,HTTP 状态码无法具体表达各种错误场景。
    ——————————————————————
    但是实际工作中会有个问题,很多人觉得非 200 的 http 状态码就是服务端问题,他觉得这完全是服务端的 error。。。
    pb941129
        59
    pb941129  
       2019-11-12 09:38:46 +08:00
    这个 看情况吧
    比如用户在未登录状态下请求访问某需要登录的接口 那当然返回 http 状态码 403 更合适
    但是如果是接口本身没有某项数据 用户有权调用该接口 那就最好返回 200 状态 说明接口访问性没问题 error code 写在 json 中 表明数据有问题
    所以我倾向于 http 状态码用来表示接口可访问性 error code 用来表示结果数据正确性
    daguaochengtang
        60
    daguaochengtang  
       2019-11-12 09:54:52 +08:00
    不知道六字真言在这里是否适用?
    grzhan
        61
    grzhan  
       2019-11-12 10:20:49 +08:00
    之前为公司制定过 HTTP API 标准,所以那时候看了不少其他公司的方案,不过多数是海外的公司,微软、Google、Github、Paypal、Zalendo 等等。
    我想知道国内有哪些公司的公开 API 标准不管错误还是正确都是以 200 状态码返回的,有相关资料吗?
    11ssss
        62
    11ssss  
       2019-11-12 10:27:47 +08:00
    首先说 http 状态码不是描述业务的 ,我同意.
    其次表达个人观点, http 状态码本身就是描述服务状态的 看到有人说直接返回 4xx/5xx 是憨憨 或 xxx 的 我只想说 你有代码规范吗?你有技术追求吗? http 状态码才是规范的 通用以及最好对接的方式. 至于业务代码合理的使用方式是在你 4xx/5xx 的时候,包含在你的 payload 里的.
    bearxu
        63
    bearxu  
       2019-11-12 10:41:33 +08:00
    必须是 200 的原因主要是 有段时间很多 isp 都会劫持大于 400 的响应插入广告
    不过这年头都是 https 了,没那么容易劫持了吧?
    skiy
        64
    skiy  
       2019-11-12 10:49:21 +08:00
    网页状态码太少了,不足以表达所有的意思。

    不过我现在是业务代码跟网页状态码组合起来用。我其实不喜欢只用网页状态
    vibbow
        65
    vibbow  
       2019-11-12 12:45:54 +08:00
    200 + Code 的路过
    metrxqin
        66
    metrxqin  
       2019-11-12 13:51:26 +08:00
    刚巧前些时间发内部邮件讨论新的服务端响应代码格式,供大家参考:

    [![snipaste-20191112-134509.png]( https://i.postimg.cc/9QD4wmGm/snipaste-20191112-134509.png)]( https://postimg.cc/zy1D91t6)
    arnoldxiao
        67
    arnoldxiao  
       2019-11-12 14:13:50 +08:00
    code=0 是正常,其他则异常
    liuzhiyong
        69
    liuzhiyong  
       2019-11-12 22:37:21 +08:00
    既然“都很反对”,那就不要固执了。这东西灵活处理,没关系啦。
    Zach369
        70
    Zach369  
    OP
       2019-11-13 09:45:16 +08:00
    感谢大家的意见.我最近琢磨了下... 我绝对灵活点.... 想怎么用就怎么用..
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3509 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 00:45 · PVG 08:45 · LAX 16:45 · JFK 19:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.