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

[watanuki]

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

[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]

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