请问给 App 开发后端时，错误码应该使用 Http 状态码，还是放到返回的 json 里？

[zhbzhbzhbz]

如题，我知道是一个老生常谈的问题了，也翻了下 V2EX 上的帖子。 App 是那种经典的资料 /博客类 App 。 主要是想知道 [现在一般国内主流] 是怎么做的？就是比如给 Android 和 IOS 开发的话。 比如最基本的用户名已存在啊，用户名格式不对啊，如果按照传统 RESTAPI 的话应该放到 http 状态码里，但是一旦错误类型多起来就得自定义

[liaojl]

这两个不冲突吧，发生错误时，http status 500 ，同时把业务的错误码放在 body 里。

[leafre]

http code 当然 http response ，business bode 放 result object to json

[mostkia]

HTTP 状态码用来说明通讯问题，json 里放业务逻辑的状态码比较好，否则后期维护可能都不知道哪里出问题了。

[ZeroClover]

RESTful 也不是 HTTP Status 里面放了错误码就不需要在 Body 里面返回具体错误原因了。这方面学习下 GitHub

[MrSheng]

个人支持放 body 里面，处理逻辑复杂度下降一个数量级

[zsdroid]

@zed1018 #17 世界上没有银弹，restful 又不是万能的。照你这么说，地球为什么要有这么多国家。直接一个地球国不就好了，战争也没了。

[wolfie]

@lff0305 #5
你说说什么场景会在业务上返回 404 ？？

[wolfie]

大多数业务错误场景，状态码肯定不能是 200 。
比如字段校验错误，给 2xx 、还是 4xx 。

https://s2.loli.net/2021/12/25/eEokV6wHMP8xdLB.jpg

[FrankFang128]

请参考 GitHub API v3

[thinkershare]

HTTP 状态码放 HTTP 状态错误, 可以认为是服务器对状态的统一描述, 使用 401 表示 405 各种大类型的错误, 逻辑约束错误返回 403(body 中定义具体错误格式, 只在有错误的情况下 body 才返回错误结构的 json, 200 的时候直接返回调用的结果, 而不是总是包一层), 找不到返回 401, 没有错误 body. 如果实在想偷懒, 也可以简单粗暴, 全部返回 200, 然后总是套一层 Result 结果, 将主体结果内容放置到 data 中, 使用 code, message 等顶级属性描述服务器响应的正确性.

[yhxx]

大多数业务错误场景，状态码一定要是 200 。
HTTP 状态码给个 5XX 说明你的服务器炸了。
已经能知道是业务错误，说明请求是正常接收到了的。

[learnshare]

HTTP 状态码是基本信息，代表 HTTP 请求的状态，是有国际标准的
业务逻辑当然是放到 body 里

两个都要有，合理使用才是最有效的

[IvanLi127]

两边都放。业务错误，HTTP 状态码 4xx ，具体错误代码放在 body 里。
另外，HTTP 状态码是受服务内容影响的，不然要三位数的状态码干嘛。。。HTTP 能返回 404 ，难道是指 HTTP 服务器找不到吗？

[fkdog]

一般来说都是结合 http status 和业务状态码一起用的。
40x 系列表示这些请求已经进入到了应用内部处理，但是由于请求参数不对、权限不对、url 路径不对等原因应用内部返回了这些错误状态码。
50x 系列表示 http 请求中间经过的某个网关发生了异常、超时，或者请求已经进入到了应用内部但是应用内部出现异常等原因。

200 表示请求已经已经进入到了应用内部处理。至于业务里出现的一个错误码，比如余额不足、账号未实名认证啦这些，当然需要添加一个 code 表示异常错误来方便前端进行处理。

其实业务 code 和 http status 也有重叠的地方。比如查找 id=1000 的 book ，https://xx.xx/detail?id=1000 ，你就会去纠结到底是 404 还是弄一个业务 code 。我自己的偏好是 404 只用于 url 在后端是否有对应的 RequestMapping ，对于根据某某参数、条件查不到某数据的这种情况我喜欢放到业务 code 里。这样的话 40x 、50x 系列的 http status 的功能就更偏向于运维监控层面而非业务相关。而且这样还有个好处就是内容传输协议不再局限于 http ，我可以随时调整协议格式，比如采用 grpc ，我不需要再去考虑迁移协议后怎么兼容原来 http 404 的问题，因为我的数据返回的业务 code 里已经涵盖了 http 404 的这种情况。

前端这边肯定是先进行 http status 判断，然后再进行业务 code 判断。

说到底还是因为 http status 这东西已经出现了几十年了，跟不上现在的互联网应用变化，所以国内的设计都是以实用角度出发，存粹把 http 协议当成是一个传输的载体。现在很多公司做的接口甚至都把 url 部分废弃掉了，需要访问哪个接口把服务名称写进 http 参数里交给后端做分发。

github 早期的 url 是很 restful 的，后边规模大了，也开始不 restful 了。也就 V2EX 上一群没见过世面的小学生喜欢把 restful 挂嘴上。

[swcat]

放 http status 的是没受到过运营商的毒打, 有的运营商会拦截 404

[CEBBCAT]

@swcat 那个我很多年前碰到过，不过他们拦截 html 之外的 response 吗？

[swcat]

4,5 年遇到过的, 记不得响应是什么了

[icylogic]

建议 V2EX 给这话题开个专用节点：错误码，想战的人可以每月战个痛，不想看的人就不看这个节点

[stardust21]

按目前国内的情况，支持放 body 里面，状态码只用来区分非业务错误，例如 404 就是 url 拼错了，500 是服务器崩了。放 http code 的话一个 APP 对应多个后端服务的时候，同一个 http code 代表不同的业务错误的话，客户端怎么统一处理呢

[gy911201]

@swcat 都快 2022 年了应该不太需要考虑运营商拦截了, 现在基本上都会去做全站 HTTPS 了, HTTPS 后运营商是拦截不到的.