为什么后端开发都喜欢自己定义 responseCode？ HTTP 状态码不够用吗？

[watanuki]

所有请求都返回 200，然后自己定义 responseCode， 好像很多大厂的后端接口都是在这样做的，这样做有什么好处？ 现在后端开发是不是已经有了关于 responseCode 的统一标准？还是一个公司一套标准？ 如果没有统一标准，大家在开发个人的后端项目时也会用 responseCode 吗？

[wj5868386]

感觉好多人都在犟，传输层是传输层，业务层是业务层，干嘛要关联一起，
接口正常或者异常用 http 状态码，
业务正常或者异常用自定义状态码，
这样有什么疑问吗？
还有的前端非要犟。

[wj5868386]

然后 我说犟这些的前端或者后端，开发经验都不超过 2 年，
就算超过了也是那种半吊子。

[sansanhehe]

多数情况下，一起用。例如 http 403，就可以返回 403001 - forbiiden reason1, 403002 - forbiiden reason2

[ChanKc]

常见问题：
讲状态码就是在讲 restful 吗？
我觉得不是，restful 的核心是超媒体。HTTP 状态码只是语义上的辅助。全部 200 也可以是 restful 。
HTTP 状态码够用了吗？
我觉得够用，而且你可以在 body 里加上具体业务的状态码。
如果 HTTP 状态码被中间的网络服务改了怎么办？
如果 body 不被改的话，像 RFC7807 那样把 HTTP 状态码写一份到 body 里也是可以的。
全用 200 有什么好处？
增加就业。

[joesonw]

RESTful 主要还是在 openapi, 对外公开的 api 使用. 内部业务复杂, 一般不怎么用吧.

[ChanKc]

@muzuiget 我也是 restful 信徒，但我几乎从来没在真实的系统上见过真正的 restful 接口（ GitHub 勉强算）。这就像是我信仰共产主义但是从来没见过共产社会

[no1xsyzy]

仅 200 是 HTTP 时代抢戏 ISP 逼出来的
仅 POST 是比上面那个更抢戏的 ISP 逼出来的
但把 “别人的失误或恶意” 归类为 “定律” 并认为 “就应该遵守能适应这一情形的方法来开发” 的各位，
@sunny352787 #9
@Vegetable #23
@tt67wq #26
@fatedier #28
@kdwycz #29
请自觉被休谟剃刀剃掉。

摘一下上期的阮一峰：
休谟剃刀：从一样东西是什么，无法推导出它应该是什么，即无法从事实推导出价值判断。

[IamUNICODE]

好不容易来 v2 摸鱼，居然又看见这个讨论

[no1xsyzy]

至于业务错误返回业务 “码”，本身已经够诡异了。
前端初判丰富提示，后端真判仅报错误。

[wizardoz]

我是后端，我不喜欢所有请求都返回 200 OK 然后在 body 中带自定义错误码的方式。但是我接触过的几个前端都是习惯这种方式。
HTTP 状态码确实不够用。
我的实践方式是自己定义一套错误码和错误提示，然后尽可能把它归类到 HTTP 规定的错误码中。前端可以通过 HTTP 错误码做一个大体的判断，然后可以通过返回数据展示给用户更加详细的信息。

[tt67wq]

这种没有对错之分，也没有好坏区别的争论有啥意义？这不是看个人喜好和团队习惯吗？

[Peiel]

http 状态码和业务的状态码最好还是分开

[hxtheone]

不够用

[976683240]

我们单位是分开的,所有接口均返回业务逻辑字段 code,code=0 为业务正常,http 的单独处理

[cco]

讨论了好多次了吧~~ 爱咋用咋用！离开业务谈这个有个屁用，劳资 hello world 项目就用 http code, 公司的业务比较多，就业务和 http 分开。

[qwerthhusn]

这个是月经帖
我们是这样弄的，正常响应错误码 200，返回响应内容，不外包装一层，不使用像 201 这样创建成功的响应码

非正常状态使用非 200，然后响应体是{"code":"", "data": {}, "message": ""}，自定义错误码，HTTP 状态码视情况定，401,403,409 这些，但是客户端不关注，只要看到不是 200，直接去取自定义错误码和错误提示去展示，所以 HTTP 状态码这里只是形式化的意思意思一下

[qwerthhusn]

@kdwycz 我感觉历史遗留习惯应该是 WSDL 开始的，WSDL 只能自定义业务错误码

[ty89]

@muzuiget 是的， 对 restfull 的原教旨主义者感到害怕。而且当年某米路由器还会臭不要脸的拦截 404 、503 之类的状态码，返回他们的个性化页面。

[yulitian888]

人家有学名的，Http 协议的 Status Code 啊！从来没说过是业务逻辑码吧！
一个典型的问题，我给 API 编写了一个 504 返回值（原意是网关超时），作为调用者，你认为是服务器端发出的业务错误呢，还是认为遇到了一个网络问题？
不读文档，没人知道你是指的什么意思啊！
好，你说每个人都配上正确的文档，大家都知道了这是一个服务器端的业务错误代码。那么好，问题又来了，真的遇到了网关超时问题——千万别说一个程序不会遇上网关超时吧，然后怎么表达呢？

来来来，做一下选择题呗，REST 是一个：
A：国际标准
B：国家标准
C：行业规范
D：学术观点

[fatedier]

@no1xsyzy 不要一上来就扣帽子，或者做什么扩展延伸的言论。

技术问题就只讨论技术。上面已经说了：

> 要考虑你的服务前面会挡各种网关，代理，网关和代理也会有自己 HTTP Response Code 的语义。

HTTP 本身只是一套协议，用于内容传输，而不是业务处理。可以借用 HTTP Response Code 返回业务内容，但会造成某些冲突风险。例如，业务接口返回 500，和 nginx 代理返回 500，可能含义并不相同。那么要正确处理，就需要客户端感知到这个 500 到底是哪一层返回的，比如通过某个特殊的 header 字段表征。

具体如何使用，可以根据具体的场景，上下游服务方来设计，需要考虑周全。而不是看过一些文章就觉得自己无所不能，可以抨击一切，要避免眼高手低。