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

[azev]

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

不知道大家是怎么做？

[fiypig]

一般都自定义啊，code 自己设置

[manami]

一般的 http 状态码不够用才自定义

[LeslieLeung]

跟你的做法一样 我觉得 http 状态码和 json 的状态码是要区分开的 json 的状态码设计可以参考阿里开发手册 可以很方便定位问题

[shenjinpeng]

以我接触过的大部分前端来看, 他们只认 200 ,其他一律服务器错误 ... 让他们根据 http code 做出相应的逻辑处理难比登天 .

[IvanLi127]

2021 年了，我还是没找到为啥要在正常的响应中，额外在响应体里套一个 code 的合理性。。。 我自己的项目里都是直接用 http 状态码来做的，没遇到不够用的情况。具体错误信息响应体里带，也挺够用的。额外信息在请求头、响应头中带。平常看访问记录也很清晰

[guyeu]

当年信了 V 站的邪，用 status_code 来定义业务异常，加了好多自定义的状态码，很蛋疼，想换回去。

[ChoateYao]

实际上来说，http code 完成足够使用，但是额外在 json 中定义一个 code 主要是用于前端交互使用。

比如注册接口，App 和 Web 以及大屏的交互逻辑个不一样，不同的错误需要 UI 做不同的交互操作。但是 http code 只有 403，额外定义一个 code 可以在不改后端的情况下，让前端自行处理。

[zpfhbyx]

我认为 http code 只是服务的状态 而不是业务的状态。。

[CEBBCAT]

楼主你这是转行过来的嘛…… 依据我有限的经验，服务器框架只会返回 200 和 500 给客户端，其他都是需要靠服务端代码指定的。

按说学习 HTTP 的时候会顺便学习到 HTTP 状态码的。我的习惯优先用状态码表示，其次才是在 Response 中带上状态码

[passerbytiny]

Spring Mvc 会自动给你加状态码，除非你好事的拦截全部异常然后强行返回 200 （和 response body 中的错误码）。

Http 状态码跟业务错误码是分层共存而不是互斥的，你可以用 HTTP 状态吗返回通用错误信息，然后在 HTTP 500 的同时附加业务错误码来对 HTTP 500 Internal Server Error （内部错误异常）进行更为详细的说明。（事实上，原本应该用超过 500 的状态码，来当作 HTTP 500 的详情，但是这个不如上面的方式好用。）

为了兼容性，往往会同时返回 HTTP 状态码和业务错误码。但如果只返回一个，那一定要是 HTTP 状态码，除非你的出发点就是“我 ＞ 公共”。

[azev]

@zpfhbyx 是的 就是这个意思 只要服务正常就应该返回 200 至于这个操作的响应 放在消息体里

[timethinker]

2XX：请求成功
4XX：客户端错误
5XX：服务端错误

如果只返回 200，不方便日志的收集和监控预警，因为把错误相关的信息都放到响应体内了，如果有日志相关的收集需求，那么就意味着要去解析响应体。

见过很多前后端分离的项目，不管是成功还是失败，都一股脑返回一个包装体结构，里面大多有 3 个字段（ code，message，data ），其实这三个字段不管在成功还是失败的情况下都存在冗余。

比较推荐的做法是，HTTP 状态码仍然继续使用，该返回什么数据直接返回，也不需要一股脑全部加上一个包装体，还美其名曰为规范，在请求正常的情况下，code 和 message 是多余的字段，前端其实只需要里面的 data 。

在错误的情况下（ 4XX 和 5XX ），此时统一返回一种表达错误信息的格式才比较有意义，如果仍然返回之前的包装体，那么 data 字段也是冗余的。

[azev]

@IvanLi127 @passerbytiny

有些时候服务器返回的 500 并不是自己在代码里能控制的吧？
而是服务器自己返回了 500 这个时候响应里是不是就没有业务错误信息了？
处理起来会不会就比较困扰？

[lyusantu]

@azev 服务器返回 500，可以捕获异常呀，打印异常信息然后定位到具体业务错误的代码处

[shenjinpeng]

http code 本来就是可以自定义的, 就是个状态码 , 响应内容也是可以自定义的 .
区别只是客户端是否按照协议来展示响应内容.
未登录抛出 401, 前端拦截器直接跳到登录页面
权限不够 403, 再附上一个 msg
数据不存在返回 404
前端传的数据有问题抛 400
服务器异常抛 500
等等...

但是只用 http code 并不能描述所有内容, 也不能很好定位出问题的具体位置 . 所以大多数情况下还需加上具体的内容状态码 .

[heiheidewo]

业务相关的错误码全部自定义。

200 、404 、500 这些是通知浏览器或搜索引擎的

[WeKeey]

HTTP/1.1 200
Content-Type: application/json

{
"ip": "1.1.1.1",
"country": "澳大利亚",
"province": "",
"city": "",
"isp": ""
}


HTTP/1.1 400
Content-Type: application/json

{
"code": 101001,
"message": "ip 地址错误"
}

[icyalala]

如果用 http code 来定义业务错误，以后业务复杂了会很麻烦的，
比如楼上按未登录 401，权限不够 403，以后又出现什么非 VIP 会员、非黄金会员、未预约之类的各种奇葩需求，
扩展起来就麻烦得很了。

如果 http code 和 JSON 里面使用两套 code，那开发和调试就变得麻烦。
不如统一用 JSON 来自定义错误信息，除此以外都是网络或者服务器问题。

[liuidetmks]

额外搞一套 httpcode，我感觉是给自己埋坑，把服务器状态和业务搅和在一起。

[hehezhang]

服务状态码和业务码不应该分开吗，