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

[zhbzhbzhbz]

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

[misaka19000]

状态码表示 HTTP 状态，业务错误当然是放在返回 body 里

[sutra]

国内主流好像是放在 body 里。国外主流则似乎不同。

[zhbzhbzhbz]

@sutra 确实好像是如此~

[rekulas]

我赞成放 body ，发现国外有些大平台都把错误码体现在 http 感觉有点不可思议，网关错误跟程序错误傻傻分不清

[PerFectTime]

个人做法是业务错误放 body ，数据不存在 404/token 过期 401/服务端异常 500 放 http

[lff0305]

支持 body 。body 里的状态码能说明请求真正到达服务了。要按照 rest 的要求某个东西没找到返回 404 的话，说不清到底是业务的 404 ，还是到达业务前一大串的负载均衡反向代理 k8s/istio 网关各种 sidecar 的问题

[ssynhtn]

HTTP 状态码根本就不够用

[zhbzhbzhbz]

@lff0305 感谢~~~！经验之谈

[panlatent]

REST 中使用状态码不代表着业务可以偷懒不反回业务错误码，使用状态码可以很好利用 http 工具 中间件 客户端 的一些功能和特性 。

[AdmiralDollBug]

业务错误和非业务错误最好要有比较清晰的边界，所以业务错误放 body ，非业务错误放 status code

[CEBBCAT]

都放。错误请求 4xx ，DB 挂了 5xx ，请求本身有问题比如操作用户没有的资源时视情况返回 403 、404 、400 等。HTTP 状态码便于监控服务状态

放在 Body 里是为了区分不同的错误情况

举例子来说，网络调试时点开一个 200 OK 的响应结果打开一看是个 404 的 JSON ，我简直他奶奶个腿儿

P.S. 工作中发现不懂 HTTP 的人不在少数，这可能也是 200 OK 大行天下的原因之一

[Zhuzhuchenyan]

这个问题我们之前和团队里的朋友也有一个激烈的讨论，讨论的焦点就在于，
给定一个这样的路由，/book/{bookID}，当 bookID 不存在的时候，是直接给一个 404 还是返回 200 用 Body 中的一个自断来传递错误信息。
我个人理解后面的那种做法，借楼问一下大家，
- 这时候给 200 返回值总感觉有点奇怪，是否给 400 会更好一些？
- 如果错误时返回一个特殊结构的 Body ，是否有必要在正常返回的时候也额外包装一层，比如说{error:null, ressource: T} ?

[DOLLOR]

自从所有的业务异常都用 200 后，绝大多数非 200 的异常都是运维的锅。

从此前端和后端就不用大半夜陪运维排查本应属于运维的故障了。

[Rocketer]

这有啥可争的？非 200 的 http code 也可以返回 body 啊。http 该错就错，body 里附加内部定义的错误码和信息就行了。

[CEBBCAT]

@DOLLOR 老兄，我想请问一下你们怎么做业务健康状态监控的呢？比如说各地的客户端频繁请求一个不存在的资源，或者 DAO 有问题

[whincwu]

赞同 @CEBBCAT 的观点，放 body 不利于监控，很多工具都依赖 HTTP 头部，放 body 需要解码实体内容

[zed1018]

放 http status ，不然人家协议设计一套这个是闲着蛋疼吗？只有 http status 无法描述具体错误的时候才会通过 400+body error 来描述

[chendy]

http 状态码 只区分错没错，是服务器错还是客户端错，简单区分 200 400 500 即可，直接用作错误码的话，遇到一些严格的 http 客户端 需要自己扩展状态码处理逻辑，比较麻烦
需要特殊区分的错误编号，header 里单独放一个字段，body 里也放
状态吗和 header 里的错误码 是方便各层代理统一处理
body 里的错误码 是方便水平不一的客户端都能理解

[thtznet]

这就是我讨厌 RESTAPI 的地方，无奈现在清一色的这种风格，客观得说，如果 API 设计合理，面向资源模式设计清晰的话，Http Status 的状态可以覆盖 90%的错误状态，很少存在业务错误需要把 code 放在 body 里的，如果业务错误非要放在 body 里说明 API 的设计没有完全面向资源，仍然以 action 的理念在设计 RESTful API ，但是实际情况是，一个需求非常非常难才能清晰地设计成资源模式，因为后端程序员长期接触面向对象设计思想，思维惯性在设计过程中自然而然会用面向对象的思路考虑 API 设计，不自觉的，我到现在还没法使用完完全全的 RESTful 。我感觉早期只编写 php 或者 asp 的程序员可能会相对容易点，我个人觉得对于后端来说，gRPC 才是接口风格设计的出路，不过现阶段并不方便，也不成熟，对测试也不友好，工具也不配套等等。

[lagoon]

作为 app 开发者，作为一直从 body 拿的人，我觉得其实是应该放 Http 里。

Http 的错误码设计出来，不就是干这个的吗？
不要说区分这错误那错误，如果这种说法成立，拿 body 中也搞 n 个错误码好了，因为：xx 字段错误码代表 xx 类错误，yy 字段错误码代表 yy 类错误。

合理吗？


不过我建议，还是放 body 吧。
对，和应该，不是一回事。

你放 Http 里，大家还要适应一遍。
讨论一遍，何苦呢？