大家做后端开发时 会更改响应的 HTTP 状态码吗？

[azev]

就是在后端代码把响应改成 403，500 什么的 然后返回自定义的 json 信息
记得第一次见这个好些是看豆瓣的 api 接口
对这个一直比较疑惑
这样做会不会跟服务器某些情况下自己生成的 http 状态码混淆了？
我个人倾向 不改这个响应 http 状态码 而是在 json 消息里再设置操作结果码

不知道大家是怎么做？

[mingmeng]

http 给接入层用，就是给接入 ng 用。一般逻辑层故障或者接入层负载均衡有问题才会有 http code error，这时候请求压根没打到逻辑层。

body 里的错误码用来标记业务错误，因为上游要根据不同的业务错误来做逻辑判断和区分显示。如果拿到了 body 的错误码那么 http 一定是 200，意味着接入网关没问题，逻辑层处理可能有问题

[BeautifulSoap]

上面说用 StatusCode 定义错误就够了的，是真没处理过一些复杂业务？
比如光是一个登陆错误，就有密码错误、账号错误、验证码错误、账号被封禁、账号被移除、账号频繁登陆被限制、账号被风控、账号登陆 ip 有问题，服务器内部错误等等一堆业务逻辑。这还只是账号登陆这一个业务接口。当然这些异常并不一定是每个都要细分，但是当有需要进行错误细分并进行不同业务处理的时候，你觉得 4xx，5xxx 这些够吗。当然你 status code 要从 001 用到 999 也不是不可以，但你确定真要这么干吗？

[snoopyhai]

建议 http 状态码不要去碰. 留给第三方监控. 毕竟是服务器 or 服务状态.
业务状态都在 200 下的 json 里定义

[clf]

我开发时 json 里返回的 code 并不是 http 状态码。code 是业务执行是否成功的判断。

而 http 状态码则是用通用的标准，两个区分开。

请求成功就是 200 的 http code，但返回 json 的 code 可能是 0 成功 >0 业务逻辑控制的 Code 。

请求错误（非业务错误）返回 500 的 http code，返回的 json 里的 code 是小于 0 的一个异常追踪 ID 。就是雪花算法生成的一个随机 ID 的负数，在日志系统里抛出异常的时候也会记录一样的 ID 。

角色权限相关返回 40X 的 http code，返回的 json 里的 code 是小于 0 大于-1000 内的特定 code 。

具体的返回结构：code 是业务 code，msg 是前端提示信息，data 是数据，trace 是请求的追踪 ID，version 是接口版本

{
code:xxx,
msg:xxx,
data:xxx,
trace:xxx,
version:xxx
}

[SjwNo1]

我发现有些人总是把状态码和业务 code 混为一谈

[IvanLi127]

@azev #13

如果是你开发的服务，HTTP 状态码都是可控的，一般的框架都有全局拦截器之类的东西，可以统一处理响应，尤其是异常的响应。
服务器自己返回 500 只是默认表现，你可以覆盖你自己需要的状态码。
处理起来如果困扰的话，一定是框架问题。正常的框架都能支持这个操作的。

[PerFectTime]

分开的好，揉在一起搞的想死。。

[bsg1992]

说直接用 http code 代替应用返回的状态 肯定又是一堆被 restful 洗脑的教徒

[lqs]

[icylogic]

ttk, yzmttk

[karloku]

至少 2xx 和 4xx 要区分开. 5xx 是服务器出错, 一个业务应用不应该自己使用这个码, 让框架来生成.

业务状态码是业务状态码, HTTP 状态码是 HTTP 状态码. 不能混为一谈. 两者不冲突.

HTTP 状态码是用来方便你的网络中间件, 运维工具, 以及客户端的网络请求模块进行统计和分类处理.
业务状态码是提供给客户端应用进行业务逻辑处理.

[fff333]

@LeslieLeung 阿里的手册有链接么？谢谢

[uselessVisitor]

如果使用 ResponseEntity 的话，还是 HttpStatus 比较常用吧。。

[janxin]

当然不会产生混淆。关于定义，可以参考其他厂商的做法，比如 Paypal：

https://github.com/paypal/api-standards/blob/master/api-style-guide.md#http-status-codes