为什么要区分不同的 http 状态码？想说服同事

[dunhanson]

我的个人的理解还是，这么做比较规范

但是同事的理解更多是优点好处是什么

比如用户登录错误之前的方式都是返回 http 状态码 200

{
  "code":4001001001,
  "message":"用户登录失败"
}

现在按照规范应该是，返回 http 状态码 401 ，然后 json 还是老样子

[AyaseEri]

5xx 不好判断是自己应用的问题还是 pass 层的问题，我们一般通过 4xx 能判断出 nginx 是否配置正确，503 的话就说不清了，可能 pass 层挂了，可能容器挂了，也可能手残把地址输错了。
我的意见就是，如果这个规范可能导致你们加班时长变多，那就不要实施。

[Davic1]

屎山的来源之一就是 200 一把梭?

[dunhanson]

@wolfie 很形象 哈哈

[daimiaopeng]

@wolfie 图不错

[alswl]

统一返回 200 以及统一 POST 一把梭，如果明确了错误返回结构，统一了各个基础设施的认知，建设了响应的工具。没问题，你甚至可以剥离掉 HTTP ，剥离掉 Cookies ，什么都不用。就是把 HTTP 当作传输层。

如果上面三者做不到，干嘛不遵循标准的 HTTP Schema 协议？

[jorneyr]

尽量不要把 HTTP 状态码和业务码混用。

[BeautifulSoap]

对接过一些接口的表示，返不返回错误状态码对写代码的人来说没什么区别

200 一把梭也是有它自己的好处，最典型的就是调用对方 api 的时候，只要不是 200 那你就知道这次 api 调用 100%是出了幺蛾子了，而且错误不在对方服务器上面

而区分不同状态码的话，你是没法单纯通过状态码来判断这个 api 请求到底是 API 本身出错了，还是对方服务器前面的 Gateway 或者 Load Balancer 因为什么原因出错了返回了非预期的 http 状态码。从写代码角度，反正到头来我还是得取出返回值具体分析到底是服务出错了还是其他的网络错误，比 200 一把梭麻烦多了

[kaedeair]

当使用这个接口需要授权，但是传输的数据的不是这个授权主体时，比如:
机器 A 使用 token 认证，当不同用户在机器 A 登陆时，401 就会有问题,会分不清是机器的 token 过期还是用户名密码错误
我这边都是用 json 的 code 表示对数据的处理结果，外层的 httpcode 表示数据的传输情况

[twing37]

是不是搞混了一个概念:

制定标准的意义就是为了更清晰不是么.

如果 x 公司的标准非外部,爱咋弄咋弄~ 黑话也是话.

但如果跨出门了.有个更标准的规则遵循.即说普通伐更省事

[icyalala]

单纯对于你的例子，如果后面需要区分错误类型：用户不存在、用户密码错误、用户被封禁，用什么状态码呢？

[micean]

很多时候状态码不一定是业务给的，比如防火墙，会带来困扰

[andiest]

本人遇到过开发同事乱用 http 状态码，导致 cdn 商的负载均衡算法以为源站点服务器有问题，一直切换源站点。

[weixiangzhe]

月经贴啊，每月都有这种贴子

[1000copy]

应用软件和 HTTP 的关系，就像你和电信局的关系。

你如果以自己为中心，就把电信局当成一通道，至于电话局定义的 200 ，400 这些代码，你管他呢，你只管摘机+说话+关机。至于摘机代码是啥，你管他的。你把我要传递的传递过程，如何解释，是我的事情。

你以电话局为中心，那么你就真的要考虑如何诊断，如何监控，各种屁事。

所以你是写 HTTP 插件的，还是你写软件，而 HTTP 只是你的传输通道？

学到了 HTTP 各种协议，就忘掉了软件需要封装，分层了吗。

为什么软件内需要知道通道的细节呢。知道了细节，软件就会被拴在通道上了。

今天 HTTP 定义了 200 ，300 ，400 ，500 ，明天换成别的协议，是 OK ，Failure ，你的软件就改了底朝上了啊。

[guyeu]

想问下楼上鼓吹 restful 风格的大佬，业务内部的错误码咋给客户端？ 401 Bad Request + {"err": 1001, "msg": "are you ok?"}

[chendy]

全 200 更合适
市面上的开发，知道 http status 是啥的其实都不多
直接无视这个概念，全部塞进 body 里返回可以避免很多不必要的沟通和解释
另外如果需要做分析统计之类的，错误代码往 header 里塞一份就行了

另外不是国外没人用全 200 ，只是常见的大公司接口做了状态码区分，小厂的，传统软件厂的接口也有全 200 的

[MrSheng]

Nginx 自定义了 499 状态码，请问为何不使用已有的状态码呢？

[adoal]

用 HTTP 状态码表示业务结果，需要对业务和技术都有深刻理解的老司机做精心设计，否则会画虎类犬。
HTTP 状态码数量就那么一些，而业务的结果状态数量是不可控的，随着业务接口膨胀起来，如何映射到 HTTP 状态码的分类，如何表示业务状态细节，都不是空口说一句优雅、规范就能解决的，是要实打实一个个干出来的，要踩坑踩水甚至踩屎的。
在实际架构中，可能经过 API 网关以及其它各种反代和中间件，业务状态逐级向上传递，业务状态码跟基础设施状态码在同一个命名空间，必然会导致设计工作量和难度更大。
最后，在 HTTP 状态码的命名空间里表示业务状态，受惠最大的其实是做系统运行状态监控的。但，同样的问题，如果没有业务和技术都足够资深的老司机来做设计，很可能出现监控信息的无序，失去意义，甚至搞出用 AI 过滤有效监控异常的笑话。
先不说团队素质、集成方团队素质、遗留系统对接之类的非技术问题吧。
总之，理想很美好，但是，陈皓给用户方做咨询的顾问团队能做好的事，不等于人人都能做好。

[lisongeee]

我的评价是用 json-rpc 更好一点，拒绝扯皮

[salmon5]

全 200 更合适
国外那套根本就是 hello world 级别的，没什么卵价值