后端 response code 该怎样返回？

[hlayk]

前提：前后端定义了通用的数据结构包含 data,mseeage,code,success 这几个基本字段用来去接收后端接口的数据。

场景：某一接口客户端发出的请求出现参数或后端校验等业务错误

问题：后端 http 层的 response code 应该返回什么？ 200 还是非 200 ？（呆过的不同公司有着不一样的习惯）

问题来源:主要是用的网络请求框架（ retrofit ），对于小于 200 或者大于等于 300 的 response code 直接抛了异常，但我并不想对这异常再进行解析 HttpException 中的 response body 解析出上述的数据结构，所以我拦截了 response 改了 response code 为 200 。这样的话，我对于 response code 无论是什么，我都可以同样的对象解析。

[kile]

code 是业务码，是前后端进行约定的东西。不要用和 http code 一致的方式，这样会让人混淆。。

[Jooooooooo]

0 成功, 去拿 data 中的内容

非 0 异常, 展示 msg 中的内容

[securityCoding]

success 没看懂 ,其他三个够用了

[SingeeKing]

遵从 REST 的应该是 400，不遵从就随缘来。。

[CodeCodeStudy]

code，用 1 来表示成功，大于等于 1000 的整数表示错误码，之所以用 1 是因为弱类型语言中 1 == true，让人一眼就认为是表示肯定的意思，用 1000 以上的整数是为了避免和 http 状态码混淆

[b1t]

我今天也把代码里的大于 300 抛异常给注释掉了，等个讲解

[hingbong]

我们是遵循 HTTP 定义，异常都是 4xx 5xx，当然，封装的结构也有详细的错误码

[jerryshao]

后端参数校验错误应返回 400 HTTP respond code 。
message 应返回有帮助性的错误信息，比如请求参数里的 XXX 字段长度不能超过 YYY 等等。
code 字段可以是自定义错误码，一个自定义错误码对应一个异常。

Retrofit 抛异常是对的，前端应该 catch 这个异常并做相应处理。
比如 catch 异常并分析 respond 是 400，打印日志，看是否需要提示前端用户参数错误或加强表单验证。
如果 catch 异常并分析 respond 是 500，打印日志，上报监控指标，配置 client 进行请求重试。

[hlayk]

@jerryshao 后端返回是没问题 retrofit 抛异常也对。只是后端对于正确与否的数据都是同样的封装 所以 retrofit
将异常给抛出来需要做额外的解析 如果后端返回的是 200 自定义的数据结构 中 code 再指定的话 那样就不需要写额外代码了，我只需解析一次返回对象 针对不同业务 code 做不同的处理

[hlayk]

@securityCoding code 太具体 不够抽象 大部分业务只关心成功 失败最多显示下 message

[JasonLaw]

https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#7102-error-condition-responses

[Hyvi]

非 200 。以后监控更方便搞。自定义的 code 最好自定义的错误。

[IvanLi127]

在 header 传递业务层的 code 。

[jerryshao]

@hlayk 可以是可以，但是大家在这里建议的是业界比较认可的做法。

如果返回 200，前端根据 code 字段做相关处理，那后端做可用性相关的监控就比较让人头疼。
不知道你们有没有对后端的 canary test，中文好像叫拨测？将来持续测试后端 api 的话，正常来说判断 api 是否成功就是使用这些 http respond code 。如果后端都是返回 200，那相关的测试也无法从 http respond code 获知是否成功，需要解析里面的自定义 code 才知道。

[hlayk]

@jerryshao 是的 我认为后端这样返回是对的 只是我自己代码里加了个拦截器 把所有 response code 都改写成了 200 这样方便自己统一的处理 但是写完感觉怪怪的

[oxromantic]

想想 http 的 code 有啥作用就能想通怎样用最好

举例来说，http 400 表示错误的请求，404 很多框架表示服务找不到不可达，这些都是属于预期之外的错误，在评估服务健康度的时候都需要采纳，如果混用，譬如把 404 作为常规业务逻辑（离谱点譬如搜索找不到就返回 404 ），就会产生很大的功能混淆，如果再集成一些网络日志框架（听 X 之类），简直就是业务和标准错误混合的灾难

可以参考下百度云 api 的设计，虽然百度云很流氓，但是不可否认 api 定义还是有参考价值的

另外我不同意上面说的持续测试只采用 http response code 来判断，这种属于没经历过 http 时代电信的鞭打以及没用过 cdn，永远不要相信 http response code 能代表你业务的状态，否则就是给项目埋雷

[tiedan]

code 返回 200，code 用特定错误代码，网关层写规则根据 code 转换成 4xx or 5xx

[xuanbg]

实际上有 success 表示调用是否成功的话，code 基本没啥用。因为你 success 是 false，都直接输出 message 了。有 code 啥事？

[xuanbg]

@oxromantic 对的，http response code 只能代表 API 服务本身的状态，而不能代表 API 服务上的业务的状态。把这两个状态混起来用虽然也能用，但遇到问题就很难定位到底是哪个层面的问题了。

[yidinghe]

协议层的问题和业务层的问题不要混淆吧，不然的话例如前端得到 404，可能是后端框架因为配置错误根本没将请求转发给业务层，会给排查带来不便