API 不管操作成功还是失败都返回 200 状态码，自己在返回结果里又定义一个表示是否成功的属性是从哪里传开的坏习惯？

@edis0n0 4xx 码不够用，总不能每个错误都是 400 BadRequest 吧。。。

@zaunist #80 为什么不可以，我是想用状态码代替原来的 success: bool ，如果不想区分太细 200 和 400 就够用，只是 40x 还可以再细分而已

有些人总喜欢不管成功与否皆返回 200 ，于是为了鉴别成功失败（会对应不同的响应体 schema ），必须给所有请求的响应体包裹一个 wrapper ，彻底侵入响应体，既不考虑违反 HTTP 带来的麻烦（监控等等），还导致响应体必须是个 JSON （不然没法包裹了），美其名曰方便区分「系统异常」「业务异常」，实际上连故障和错误都没划分明白（这里点名批评 Java 的 Exception 类型）。
更有甚者，包就包了，他还把成功和失败时的内容载荷给你丢到 wrapper 的同一个字段里，导致必须先把 JSON 解析一次，知道了是成功还是失败，才能用正确的类型把载荷再映射一次，病得不轻。

http 状态码用来表述协议链路状态（例如 503 504 400 ），自己 body 里定义的状态码用来表述业务逻辑的处理状态。
两种本来就不冲突，现实是很多人拿来混在一起，故障排除时反而不好弄。

一个是协议，一个是业务很难理解吗？ rpc 上网关不用业务码用什么？业务千奇百怪各种状态码需要定义和透传

200 表示系统一切正常，这样是不是好理解很多了

这个坏习惯导致各自闭门造车，不知道为什么有人喜欢浪费现有资源，自己再套一层。那群以 http 状态码不够覆盖业务错误的，想想自己是不是被 http 限制了想象力！而且在 HTTP 上封装自己的协议后，居然不提供相关工具链，简直就是重复劳动，瞎卷。

异常响应没必要和正常相应走同一套逻辑，给正常响应套一层完全没意义。还有，HTTP 标头那么好的东西，不要浪费！

http 状态码的表达力有限，不是 200 打天下就是 200+400 打天下，很多错误你确定能找到对应的状态码？就算用了少部分意义适当地状态码，不还是要在返回结果里再定义错误码？

月经贴……然后我也回过几次类似的回复：为什么不全都要呢 :doge

状态码和响应体一起用并不冲突。Http 状态码用来区分正常响应和错误响应，响应体中给出具体的错误码。当然，200 状态就没有错误码这一封装了。
也许这有点多余的认知成本，但实际上用得最多的就三状态：200 （这个甚至不用写），400 （用户输入错误），500 （服务端错误）。这不比各种业务面条来得复杂吧……

再进一步说，新的 Spring6 开始支持 RFC 7807 规范： https://www.rfc-editor.org/rfc/rfc7807 ，规定了异常信息如何返回。可参考： https://www.51cto.com/article/721281.html 。基本思路就是异常产生时的响应特殊 header 和 json body 。

当然以 Java17 的实际普及程度来看广泛要升级到 Spring6 还有相当长的时间，但我已开始期待，观望等 Spring6 普及了这一月经贴的内容是否会有所变化😀

@edis0n0 业务上的报错有很多种，统一 400 ，前端如何区分是哪种错误，还不是要引入 "code:"

混合用最好，讲真，你封装时候，无论是 外面的 status 还是里面的 code ，都需要处理