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

[watanuki]

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

[Conda]

老的开发模式大概是 code 、data 、message 这种格式，后端会重新定义返回的业务状态码，而不是依赖于 Http Code，而在 resetful 风格则没有这个业务 code 一说了。当然所有请求返回 200 也不对，400 500 一类的还是该怎么返回就怎么返回

[wangyanrui]

http 状态码不够用，所以自定义~

[cheng6563]

业务稍复杂点的系统。完全按 resetful 来就是自己找镣铐，http 那几个状态码根本就不够用。

[kanepan19]

业务 code 和 通信 code 分开 没毛病

[littleylv]

你这里说的 responseCode 不是用来代替 HTTP 状态码的。是两码事。

比如后端验证后发现，某个必填字段你没填。 返回给前端的 http 状态码仍然是 200，然后自定义一套{'code':10001, 'msg': ‘xx 字段必填’}。这不是很正常的操作吗？不然你觉得这种情况要返回什么 http 状态码

[Oktfolio]

```
public class ResultEntity {
private Integer code;
private String message;
private Object data;
@JsonIgnore
private HttpStatus status;
@JsonFormat(pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")
private LocalDateTime datetime;
}
```

个人项目的话。GET 以外的方法结果为 20x 的时候，除特殊情况什么都不返回，GET 只返回内容，没有上面的封装。有错误的时候才上面封装的内容。status 是方便在 service 层返回状态给 controller 用的，实际是会以 http 状态码返回给前端。会用到 GET POST DELETE PUT PATCH 五种 Method 。
```
public class ResultEntity implements Serializable {

private boolean success;
private String errorMsg;
private int errorCode;
private String errorLevel;
private Object content;
}

public class PageResultEntity implements Serializable {

private int currentPage;
private int pageSize;
private long totalCount;
private int pages;
private List<Object> data;

}
```
工作嘛，全用 GET POST，全返回 200，然后就是上面定义的内容了。

[DsuineGP]

restful+HTTP 状态码足够通用,但是不够符合实际的业务需求.
比如我这边有一个需要批量查询 100 条数据的接口需要实现(因为有性能要求,必须支持单请求批量查询),实际运行中可能其中 99 条成功查询到了,1 条由于某种原因失败了,那么从 api 接口上如何设计呢?
是 POST 请求然后响应 200 吗?
实际上个人这种设计不符合 restful 的语义,也不完全符合响应码 200 的语义.
最终还是要落到自定义响应码上.

[leo108]

@littleylv #5 也可能只是你自己不知道而已 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422

[sunny352787]

所以你们真的没听说过运营商劫持的情况吗？非 200 返回码给你劫持掉，导致某个地区用户投诉量剧增...

[Oktfolio]

@Oktfolio 但是我这样就需要兼顾 HTTP Status Code 和自定义 Code 。

[Oktfolio]

@sunny352787 以前的事情啦，现在应该没有了。

[guyeu]

HTTP 的 status code 是可以扩展的。。。个人认为通过通过扩展 status_code 来实现更多的响应码是一种比较好的实践。

[krixaar]

之前不是有帖子讨论过这事儿了么，就是没必要死扣标准，其中一个想法是，http 的 response code 只代表接口自己的状态，然后返回的 code 和 message 代表业务实际的状态。
比如 http 200 说明接口好的，http 400 说明你接口写错了，http 500 说明接口挂了。
返回的 code 和 message 再告诉你具体什么情况。

[sunny352787]

@Oktfolio 并不是所有用户都在北上广深啊...

[wangyzj]

http code 只是 http 访问的问题
return code 是接口返回的问题，不代表接口有错

[yongjing]

不够

[unicloud]

绝对不够！

[gushidefengzheng]

当然不一样，HTTP 状态码表示服务器服务状态，只能表示几种基本状态。
而 Response Code 是业务状态码，一套系统下来可能与上百了状态码，你可以看一下微信公众号开发文档里错误码的定义有多少个，每个状态码表示不同的问题，要的是能够精准定位。

[hantsy]

参考 github api 设计就行了，Http Status 没有必要去扩展，Error API 或者使用 Problem API 信息包含详细的描述。

https://docs.spring.io/spring-hateoas/docs/current/api/index.html

[ArtIsPatrick]

http 状态码从名字就可以看出来指的是 http 请求的状态，不是业务的状态。

[hantsy]

@leo108 422 很常见。

https://github.com/hantsy/angular-spring-reactive-sample/blob/master/server/src/main/java/com/example/demo/RestExceptionHandler.java#L38-L54

至于那些支持不管是错误还是正确都是返回 http status 200，然后用 Response Body 包装 status code，message 的人，只怕 HTTP 设计者看不懂中文，不然肯定吐血而死。

[ArtIsPatrick]

@guyeu 不是一类状态最好不要用同一个字段，业务状态还是放 body 里比较清晰。

[Vegetable]

一个是，几百个状态码真不太够，尤其是有一些还要隔离，比如 2 开头的和 4 开头的意义不同，业务多起来根本不够，自找没趣
另一个是，有些客户端对于非 200 的状态码默认是 Exception，这就有点蛋疼了。

[robotdiy]

真的是一个月来一个帖啊。

[zhw2590582]

我公司后台喜欢用 code=0 表示数据正常

[tt67wq]

有些前端或者客户端框架非 200 就会有 warning 或者报错啥的

[forgottencoast]

@leo108
没错。
客户端请求数据不完整，无论如何都不能是 200，肯定是 4xx 错误。

[fatedier]

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

[kdwycz]

早年大家都不用 https 的时候，非 http status 200 会被运营商劫持。现在的话……历史遗留或者习惯？

http 400 和返回体里面包含业务错误码是不冲突的

[back0893]

又到了我最喜欢的环节了
搬个凳子,吃瓜

[clf]

因为 HTTP 状态码一般只是用于判断请求状态的。业务方面的错误还是使用自定义的方便，避免出现歧义，省的 A\B\C 模块的问题全是一个 Code 。
我之前做微服务开发，每个微服务分配了一组编码（开头 1-2 位），抛出异常的时候会返回自己的错误编码，方便前端直接找出问题的后端。剩下的就是这个后端去找自己的日志排查错误了。

[xuanbg]

一般来说，我们只是把 http 协议当做传输层使用，业务不应该关系传输层。所有业务层需要有自己的错误码。

[Orenoid]

屁大点事隔一段时间就要吵一次，按团队规范来不就结了，真是闲的。

[muzuiget]

告诉你，曾经也是 RESTFUL 信徒，最后就鄙视这种做法。教训就是：不要用 HTTP 状态码做业务状态，HTTP 状态码就是 HTTP 状态，不要搞别的。

最简单一个例子，比如客户端根据用户 ID 请求用户数据，但是 ID 不存在，返回 HTTP 404，然而问题来了，这个 404 也有可能在数据传输路径上某个节点给你返回的，反向代理、CDN 、防火墙、中间件等等，都有可能给你一个 404，原因可能配置错误什么，查原因查死你。如果你自定义一个有容易识别的状态码，那就知道锅在哪里了。

[myon]

偷懒而已，目前我在对接的一个项目不仅都返回 200，而且都是 post 请求，调试的时候非常难受，有时候找问题从请求列表里都看不出来哪个有问题，还得一个个点进去看。
个人倾向正常数据返回正常的 http 码，异常返回异常的 http 码，然后返回主体可以有自定义的业务码

[timi]

REST 被日常吊打

[NakeSnail]

这是为了给自己在团队里输出标准找理论支持吗？

[zsdroid]

之前用 spring boot 的 restTemplate，比如账户不存在，会返回 404，和错误详情的 json 。
404 会抛出异常，就需要 trycatch，再将 e.getMessage()解析出来。
这样就需要解析 2 次，try 里用 restTemplate.getForObject 解析一次，catch 里用 JSON.parseObject 一次。

[ChanKc]

RFC7807 了解一下

[hbolive]

月经贴又来了啊啊啊啊。。。

[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 字段表征。

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

[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, 网关各个地方都可能出妖鹅子。

[v2hh]

之前公司前端要求 不让 http 的状态码，请求方式统一用 post

[ChanKc]

@jzmws 没有不安全的 HTTP 请求，只有不安全的 HTTP server 实现

[saltbo]

@DL9412 好吧 这是一种情况

[chanchan]

@yulitian888 E. a piece of shit

[arvinsilm]

不够用。业务异常的种类繁如星海

[terax]

这实际上是两个问题。

1. 为什么统一返回 200 ？
因为 401 等错误码可能会被运营商劫持。

2. 为什么要用自定义错误码？
为了报错的时候方便追查错误来源。

[krixaar]

@saltbo （以下为虚构创作，博君一笑）
code 是让你们往 UI 做 i18n 的，message 是写给你们看的怕你们记不住 code 的，要不是给你们面子我才懒得传 message，你现在还想直接把 message 弹出来给用户看？
*甩给你一个 code 和 message 对应的.docx，之后接口返回的 message 都变成了“如果你看到这条信息，说明我们前端又偷懒了”*

[GTim]

其实并不是状态吗不够用，而是浏览器不识别某些状态吗，会当作错误处理

[guyeu]

@ArtIsPatrick #22 为啥会有人认为 http status code 代表的不是业务状态。。。都 POST+返回 200 自己再包一层，那 HTTP 协议里定的 method 和 status code 是闹着玩的么。。。

使用 HTTP 协议，就最好遵循 HTTP 协议的设计，状态码代表的就是一个响应的状态。很多人自己包装是因为觉得预定义的那几个 code 不够用，那你可以自己扩展啊。。往 1XXX/1XXXX 扩展，协议甚至是鼓励的。

body 里可以有一个 code 用来表达特定协议的某种业务含义，但不应该做成通用的，通用的 code 在逻辑上和 status code 完全是重合的。对客户端来说，对两个码进行校验显然不如对一个码进行校验省事，对服务器来说，至少也能节省一个 int 值的内存空间。

[sunny352787]

@no1xsyzy 就这智商讨论个屁，就事论事说个原因还弄出人身攻击了，有多少不得已而为之的解决方案你一句话就全否定了？

[saltbo]

@krixaar i18n 这个还可以接受，但是如果没有 i18n 的需求是不是 code 就没有存在的必要了？

[kkkwar]

@leo108 很多时候，不同的业务异常场景，前端要显示不同的文案；后端只能定义多种状态码，显示文案是前端自定义的。

[charlie21]

这个倒不是标准的问题。苹果有苹果的标准，梨子有梨子的标准。你拿苹果的标准套梨子，你无聊而已

这属于分层设计，设计得自洽即可

[saltbo]

或者 讨论一下：i18n 这种需求是不是后端在偷懒？ 如果仅仅是为了 i18n 的需求定义一套错误码，搞得两端都得维护，为什么不把 i18n 放到后端来做。

[no1xsyzy]

@fatedier #60 如果我的观点在哪篇 “文章” 里出现过还请指教。
我突然发觉又不记得扣帽子是个什么意思了，查查「比喻对人或事未经过详细的调查与分析，就轻率的冠以某种罪名。」，然而我的话是建立在深刻的洞查上的，如果你能看透这一讨论的多方的思维结构你会发现你的这个想法毫无意义，到底哪层的 500 不会影响客户端的行为。
不过之前的回复的时候忙着下班，没来得及把楼上所有的观点容错测试一遍，再多等我会。

[blessyou]

不同模块的错误码分成 100xxx , 200xxx, 300xxx 比较好排查

[saltbo]

这样虽然还是得定义一个码，来对应不同的 lang，但是后端自己来维护就行了，也就不用输出到接口里了

[w99w]

对于这个问题，请没有做过系统设计和架构的 coder 歇会儿。

[RJH]

是的，真的不够用，业务相关的错误码随着业务的增长不断增加。

虽然 HTTP 协议是支持自定义状态码，但是目前有些工具或者是语言对这块的支持并不好，我遇过设定状态码为 9999，在 postman 上无法识别。

[sunny352787]

来，翻页继续