api 接口 http 响应码问题?

[Zach369]

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

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

返回格式必须是:

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

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

[shakaraka]

月经贴

[lcy630409]

- - ，各位来吧
我赞同 code 等于状态
大概是用 thinkphp 习惯了

[pelloz]

不要教条，哪种方便用哪种，混着用最方便

[TomVista]

这个无所谓,写好文档,定义好格式,就够了.

[fengpan567]

格式没问题，三部分都有。但是错误码还得根据自己的业务来，我自己设计接口也不会把 200 当成成功返回值。

[lcy630409]

之前和一个 windows 软件开发的同事对接过，
他们也是喜欢 code=1 是错误，0 是正常，
我就喜欢 code=1 正常 0 错误.....

[Raymon111111]

0 表明正常, 其它表示异常.

实现的又不是 http 协议, 用 http 协议的规范是有点奇怪的.

[zxcslove]

@lcy630409 估计思路是这样的：前一种只有 1 和 0，后一种 0 是正常，异常则有很多种。

[Smilencer]

随意

[zhuweiyou]

因为这个 code 你要理解成 error code，所以 0 是正常，才是对的。

[zqguo]

问题不大啊，规范好就行了，没啥纠结的。

[HangoX]

我不明白的地方是，如果用 http 状态码表示的话，反正我都要解析内容，那我干嘛还要管 http 状态码？

[FinnBai]

快成周经贴了

我支持响应部分 HTTP status code，成功时 "code:0" 完全没有必要，直接返回数据

[wangkun025]

我用状态码

[Hopetree]

他们要所有接口都返回 200 应该是考虑的前后端分离，现在前后端分离的话，按照这种返回格式给前端去判断其实也挺好的，所以说两种方式没有哪种更好，看需求，怎么好用怎么来呗

[wangyzj]

0 位正常,其他则为异常.
我现在就是这样

[dallaslu]

把整个 HTTP Header 都在 JSON 里写一遍，爱用哪个用哪个。

[rogwan]

code = 0 是有 sub_code 的含义，用于标注业务状态

[kwanzaa]

没问题，但是要写好文档。400/500/等异常处理要很明确协定。

抛个 http code 就不管的人都是憨憨。

[riverluoo]

双方约定好 就好了

[chanchan]

反正我觉得 http status 不是用来描述业务的

[binux]

我现在觉得国内这个状况就是能力问题。
大部分人连 HTTP 状态码是什么，有哪些都搞不明白，你让他们处理非 200 自然是不行的。

无论在英国还是美国，和别的开发者交流，按照语义返回状态码都是理所应当的。如果你说统统返回 200，他们还会问为什么。

[yulitian888]

这个视情况而定的。
如果终端是服务器调用的话，两者皆可，自行约定就行。但是如果终端是浏览器的话，你用 http 的 4xx，5xx 返回，信不信有浏览器厂家给你夹带私货、偷梁换柱？比如某些国产套壳浏览器遇到 404，会重定向到浏览器自带的 404，页面里面还给顺手加点广告。

[icebay]

@yulitian888 #23 application/json 也会这样吗？

[back0893]

战起来
上次战了几百贴

[reus]

@binux 他们又没有被“智能路由”、“智能浏览器”劫持非 200 返回的历史……

[whp1473]

最大问题是 Http 的 Code 码是 3** 4** 2**都是有规定含义的，浏览器表现也不同，用这个一些自定义的返回很难说明。前后去过的两家公司都是统一返回 200，内部状态码判断 msg 说明错误描述 value 返回值

[KuroNekoFan]

随便吧，不正常的 status 和 data.code 都 reject 掉就完事了

[daiqiangbudainiu]

@binux 3xx 4xx 5xx 是给 nginx 返回的，服务端的程序只要能返回数据，就说明 http 200，错误都是服务端程序自己定义的错误，很多都是业务上的错误。比如自己写的业务代码也反 500，那就不够直观的判断是 nginx 返回 500 还是程序返回 500。所以要求程序全都反 200 的 http status，其他的东西都放到 response body 里边自己去判断

[Lonersun]

我们是这样搞得：
200 定义请求成功，
400 定义业务异常，再进行业务细分，返回具体的错误码及错误信息
500 定义服务异常，

[binux]

@warcraft1236 #29 你连判断 Nginx 还是程序的错误都做不到吗？

[jonahtan]

200 查询成功(GET)
201 操作成功(POST/PUT/DELETE)
400 业务处理异常
401 鉴权失败
404not found
500 服务处理异常

具体的业务错误代码放在 response 的 code 里面。

[realpg]

习惯 1 0 和负数表示法

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

定义为 status

1 为通常状态正常
0 为非业务逻辑状态非正常
负数为各种针对每个业务的错误代码

[dcty]

谁给钱谁说了算

[daiqiangbudainiu]

@binux 注意，是方便两个字，要的是快速。你要是抬杠那就没意思了。写代码还能用记事本呢，还不需要任何代码提示呢

[daiqiangbudainiu]

@binux 另外，为什么国外的程序员觉得直接用 http status，就代表是对的？

[fkdog]

我来总结一下，

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

小公司增删改查没多大复杂业务的，妄想几个 http code 来解决业务需求，脑子烧坏了把。

[bfqymmt]

@back0893 有上次的大战贴吗？学习一下

[telami]

非常认同 rest 中关于 url 是资源定位符的概念，增删改查对应 post、delete、put、get，但是返回 http 状态码简直就是灾难，联调时返回 404，已经无法辨认是不存在这个接口，还是不存在 [user/1] id 为 1 的人

[jabin88]

遵循 HTTP 响应码 这样最好。我见过很多合作公司的文档都这样

[KyonLi]

/t/611572
/t/392234
/t/496047
/t/476162
/t/324812
/t/191534
/t/578131

[caryqy]

http code 那几个不够用啊

文档写好就行，每个 code 对应的什么含义

[xuanbg]

这种封装结构其实是 OSI 模型分层思想的体现。http 协议在 OSI 模型中对应的是第 4、5、6 三层，webAPI 对应的是第 7 层。高层的应用当然不需要也不应该去干涉更低层的逻辑。

[xuanbg]

原教旨主义的 REST 实际上混淆了应用和数据传输，违反了分层的思想。导致了更高的耦合度和逻辑的复杂化，在我看来是不可取的。

另外，搭车问一个问题：验证短信验证码的 url 该如何定义？该使用何种请求方法？

[yulitian888]

@IceBay 以前遇到的，但是没注意当时 Content-Type 是什么

[lihongjie0209]

随便在聚合数据上找了一个， 你用 http code 定义以下这些错误代码。https://www.juhe.cn/docs/api/id/54

还有， 一个协议层的 code 居然会和业务关联， 如果以后需要使用 tcp 模式的 rpc 调用， 你到哪里去找 http code ？

[gamexg]

@lcy630409 #6 0 为正常的好处是 其他值可以作为错误代码提供更详细的错误信息。

另外 http 的那几个错误代码根本不够用。

[Tokin]

@gamexg 应该是用 http 状态码归类吧，具体错误和错误代码还是要在主体中返回。
我用了一段时间 http 状态码，一直难以适应。

[ryougifujino]

看了之前那个讨论贴，总结一下个人感觉最好的：所有 http code 还是按正常语义返回。正常情况下直接返回数据，不包一层。在有错误的情况下，如果有必要对话，在 response body 里面定义更详细错误码。

[itechify]

我又看了上次 300+回帖打架起来的帖子，继续战起来战起来🤺

[ggicci]

不要问，问就是 RESTful 和 GraphQL

[nvkou]

@fkdog 几个？没说不准自定义啊。code 250：查询成功，但服务器闹脾气了，回滚了操作。

[nvkou]

@lihongjie0209 教条主义：restful 只用 http （ s ）

[whileFalse]

body 按 JSON 风格，code=0 为正常。
HTTP status code 按语义。
协议走 HTTPS。以前有的运营商会劫持非 200 返回，现在不清楚。
API 使用者只要按 JSON 解码并查看 code 即可。如果 JSON 解码失败说明服务器不正常。
HTTP status code 用来进行具体业务无关的宏观统计。比如监控 5xx 的发生率等等。status code 没必要分的特别细致。

[alphatoad]

GraphQL 天下第一

[zr8657]

月经贴别战了，甲方说啥干啥呗，混口饭吃得了，有那功夫纠结不如去干点自己喜欢的事

[vultr]

@Lonersun #30 我们也是这样子处理的。

[killerv]

http 状态码按照实际业务来返回，不要全部都是 200，不过 body 中还是要指明 errCode，HTTP 状态码无法具体表达各种错误场景。
——————————————————————
但是实际工作中会有个问题，很多人觉得非 200 的 http 状态码就是服务端问题，他觉得这完全是服务端的 error。。。

[pb941129]

这个 看情况吧
比如用户在未登录状态下请求访问某需要登录的接口 那当然返回 http 状态码 403 更合适
但是如果是接口本身没有某项数据 用户有权调用该接口 那就最好返回 200 状态 说明接口访问性没问题 error code 写在 json 中 表明数据有问题
所以我倾向于 http 状态码用来表示接口可访问性 error code 用来表示结果数据正确性

[daguaochengtang]

不知道六字真言在这里是否适用？

[grzhan]

之前为公司制定过 HTTP API 标准，所以那时候看了不少其他公司的方案，不过多数是海外的公司，微软、Google、Github、Paypal、Zalendo 等等。
我想知道国内有哪些公司的公开 API 标准不管错误还是正确都是以 200 状态码返回的，有相关资料吗？

[11ssss]

首先说 http 状态码不是描述业务的 ,我同意.
其次表达个人观点, http 状态码本身就是描述服务状态的 看到有人说直接返回 4xx/5xx 是憨憨 或 xxx 的 我只想说 你有代码规范吗?你有技术追求吗? http 状态码才是规范的 通用以及最好对接的方式. 至于业务代码合理的使用方式是在你 4xx/5xx 的时候,包含在你的 payload 里的.

[bearxu]

必须是 200 的原因主要是 有段时间很多 isp 都会劫持大于 400 的响应插入广告
不过这年头都是 https 了，没那么容易劫持了吧？

[skiy]

网页状态码太少了，不足以表达所有的意思。

不过我现在是业务代码跟网页状态码组合起来用。我其实不喜欢只用网页状态

[vibbow]

200 + Code 的路过

[metrxqin]

刚巧前些时间发内部邮件讨论新的服务端响应代码格式，供大家参考：

[]( https://postimg.cc/zy1D91t6)

[arnoldxiao]

code=0 是正常，其他则异常

[katsusan]

国外大厂的设计风格：
https://developer.github.com/v3/
https://github.com/paypal/api-standards
https://cloud.google.com/apis/design //mainly grpc design
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
https://developer.twitter.com/en/docs/ads/general/guides/response-codes

[liuzhiyong]

既然“都很反对”，那就不要固执了。这东西灵活处理，没关系啦。

[Zach369]

感谢大家的意见.我最近琢磨了下... 我绝对灵活点.... 想怎么用就怎么用..