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

[watanuki]

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

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

来，翻页继续