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

[watanuki]

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

[baiyi]

都快成周经贴了。

来说下我对 HTTP Status Code 的理解：
HTTP 是在 REST （ Representational State Transfer ） 的指导下设计出来的。进行状态转移的是各个组件，组件可能包括浏览器这样的客户端，网关、代理这样的中间层组件，HTTP 状态码就是给它们用的。HTTP 本身就是这些组件的统一接口。
如果你想返回的资源需要在这些中间件进行处理，那么你需要返回一个合适的状态码。
如果你不依赖这些组件，那么为什么不用 RPC 呢？

再说 response 中的 code：
它的本质上是接口响应的错误消息，它不能代替 HTTP 状态码，也不能用 HTTP 状态码去代替它。
无论返回的是 `{"code":1}` 还是 `{"message":"error message"}`，都没有区别，只不过客户端不倾向于使用字符串来做判断，更愿意使用不容易改变的数字符号。

[Vegetable]

@no1xsyzy #47 没搞懂你的意思。仅 200 时为了讲业务层和网络层完全区分。前端可以根据 HTTP 状态码判断业务之外的逻辑，实际上这部分更多是浏览器在处理。前端处理业务逻辑本身，而不需要再研究 404 究竟是 URL 拼错了还是没有这个对象。
可能某些特定的环境催生了这个做法，但是现实就是没有银弹，HTTP StatusCode 远远不是。

[qW7bo2FbzbC0]

我们这边分离，业务逻辑的 code，和接口访问性质的 code

[qloog]

@zhw2590582 我也喜欢用 code=0 表示数据正常，其他的都是大于 0 的，可以参考新浪微博的错误码设计： https://open.weibo.com/wiki/Error_code

[ParallelMao]

@littleylv 4xx

[shenlanAZ]

我现在建立了一个比较适合现代 restful 的对象结构

state，msg，data 。

state 有两个值，分别代表成功和失败，这里指示的是业务级的成功或失败，比如你保存了什么东西后端校验为失败，这里的状态就会为失败。

msg 和 data 在任何情况下都可以有 也可以没有。

如果未授权或者其他的 还是用的 HTTP 本身的状态码。

[haha370104]

首先，我们假设需要对所有接口访问都增加日志方便线上错误排查，合理需求对吧

其次，因为接口返回是有敏感信息而且数据量可能很大，所以日志不能记录 response body，也非常科学对吧。

然后我的服务器是一个集群，里面有上百个节点，也非常常见对吧。

假设有个接口 GET /api/some_source/{id}/some_field，作用是获取某个资源的某个字段，这个 path 的设计也非常 restful 对吧

接下来的事情出现了，我作为一个业务开发动了一下这个接口的逻辑；其他人更新了 nginx 配置，但出于种种原因没有生效于所有节点，可能只有 1 个节点会报出 404 。

接下来线上开始 404 错误率飙升，dev 环境「可能」无法复现（可能从业务代码来看这个资源的访问和用户状态有关，dev 环境 nginx ），然后你完全不知道是因为 nginx 导致的还是业务代码导致的。现在你唯一能做的就是让接口调用者（最好是前端，因为发布快）赶紧打一段日志配合排查问题

是不是觉得 restful 原教旨蠢了起来？还是那句话，基于单一责任原则，httpCode 最好只用来表示请求本身的状态；业务状态你用业务 code 来表示

[cumt21g]

@sunny352787 老司机啊

[keepeye]

不要把错误码和状态码混为一谈行不？

状态码咱也用啊 比如 401 500 之类的

[littlewing]

不够
HTTP 状态码并不能表示业务上的各种异常状态

[justin2018]

一个是业务状态码 一个是 http 状态码~

[A3m0n]

发现一个有趣的状态： https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/418

[saltbo]

我一直觉得业务的错误码没啥用啊，谁能给我说说你用业务状态码来干啥。有个错误描述不就够了么？

对客户端或者前端来说，判断 httpcode，400 以上弹出错误描述，over.

[constructor]

这个月经贴很有价值！看得不亦乐乎

[DL9412]

我们一开始想用标准的 http 状态码表达错误状态，但各种奇奇怪怪的错误提示实在是太多了。最后只好改成捕捉 200 以外的所有错误，然后拿一个自定义的错误码去对表报错

[saltbo]

@DL9412 为啥要搞那么多错误码呢，定义一套错误码，前端和后端都得维护，直接由后端管理错误提示不香么

[Garland]

请求成功和具体的业务逻辑成功是不一样的

[DL9412]

@saltbo 我们是做翻译系统的，网站要做本地化，目前本地化是在前端做的，提示想要跟着本地化，也就在前端做了，后端不用去管前端的语言状态。

[jzmws]

月经帖, 方便自定 responseCode http 状态码只是标识这次通信他已经成功了 ,并不能说业务时成功的

```
{
code : 0 ,
msg:"成功",
data:{
xx:"xxx"
}
}
```
这样不香吗 ? restful 的风格 ,其实你们都没注意到 post /get 除了这两个请求 其他都是不安全的 http 请求

[renothing]

非要拿 http status code 当业务返回 code 的人，应该是还没踩过坑的。cdn, proxy, 网关各个地方都可能出妖鹅子。