api 接口 http 响应码问题?

[Zach369]

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

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

返回格式必须是:

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

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

[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 掉就完事了

[warcraft1236]

@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]

谁给钱谁说了算

[warcraft1236]

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

[warcraft1236]

@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 响应码 这样最好。我见过很多合作公司的文档都这样