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

[dunhanson]

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

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

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

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

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

[cxe2v]

200 一把梭可以避免很多麻烦

[NCry]

http 状态码目前在我这边使用过程中就是拿来给浏览器看的，实际业务中并不会用到。

[zmal]

可以看看 https://coolshell.cn/articles/22173.html

[wolfie]

[ZE3kr]

还有一个好处，就是 Nginx/Apache 不用解析 json ，可以仅根据状态码记录 Log （比如仅 5xx 的记录 log ，其他的不记录。如果因为种种原因愿意通过 Nginx 记录日志而不是其他地方的话）

[Chad0000]

我是一律 200+Post ，虽然有点不规范但省了很多事情

[gam2046]

没什么优点。特别是 API 请求，有效的状态码可以让浏览器为用户显示友好的错误提示，但 API 请求，几乎不存在用户直接请求的情况。

REST 那一套说是可以更有语义化，但由于实际业务的复杂性，依靠 HTTP CODE 很难表达出含义，最终还需要在响应体内自定义错误码，这就是重复工作了。

统一返回 200 以及统一 POST 一把梭，确实不够优雅，但是能用，而且也没什么副作用。

[yuxing1171]

也就见国内公司的经常用这种 200 走遍天下，无视 HTTP 状态码，国外的 API 很少见这样做的。这种格式给调试造成非常大的困扰，看着就恶心，已经到了走火入魔的地步，严重阻碍技术的进步。公司刚招了个毕业没多久的，问 HTTP 状态，基本啥也不知道，一问是原来的公司都是这种做法，自己 body 里面定义状态码，从来不关系 HTTP 自己状态码，真被害的够惨的。 这种格式早期是为了应对国内恶心的运营商拦截消息而不得已的做法，但是现在因为普遍使用 HTTPS ，已经没有了这种情况，还继续使用真没必要。

[andyskaura]

现在的做法是 只要是业务返回 统统 200 即便有问题

[monkeyWie]

业务层一律 200 ，非 200 的应该是网关层的事，对接飞书 Open API 的时候也是这样设计的，如果是业务异常都是 200 ，但是触发限流之类的网关层异常，就是非 200 了

[yuxing1171]

200 走遍天下，对于调试和监控都非常不友好。调试的时候不得不解析 body 才能知道是否真的成功。而监控更加困难，通常监控不会去解析 body 数据，都是 200 那你让监控怎么判断是否成功？

[hope4tomorrow]

做监控的话，用标准可以省很多事，例如，在 prometheus 中查询非 200 响应的记录，就很自然

[cpstar]

一个写在 ajax.error()里，但这就不能区分协议基础问题和业务故障问题
一个写在 ajax.ok()里，然后 if errcode ，这就区分了协议基础问题和业务运行问题

[JamesMackerel]

@cxe2v 一个典型的例子就是，调用方如果是 Java 服务用的 RestTemplate 的话，那么除了 2xx 之外会抛异常，需要额外的配置才能不抛异常……

[masterclock]

如果已经有规范，比如 RESTful ，那就按照规范来
如果还没有规范，那就起草个规范，然后按照规范来
但说实话，这好好的，干嘛要自己去发明个轮子

[angryfish]

首先问一个问题，返回 401 装态，和返回 200 状态，前端的工作量有变化吗？后端的工作量又变化吗？
作为使用 spring boot 的，我觉得返回 401 ，后端的工作量是增加了的。不知道前端是否会增加。

[Leonard]

整个项目统一，别随时改一会是这一会是那就行

[Jooooooooo]

用 http code 的问题在于, 很多时候, 得判断两次.

异常状态随便举例子 下游调用超时, 内部异常(比如空指针), 下游异常数据, 用户没登录, 用户状态不正确, 用户行为不正确, 可能是爬虫(返回打乱的数据), 可能是爬虫(不返回数据)

我们是用自定义 code:0 表示正常, 其他值表明是各类异常.

[Lin0936]

最恐怖的是现在项目 API 有的返回 200+错误 json ，有的返回 401 。。。

[dunhanson]

😂 看来争论挺大的