很多人，接口设计都是纯 200，然后 BODY 类似：
{ "code":0, "message":"", "data":null URL 类似：
/user?id=1 这样。 刚开始我也试图遵守 RESTful 范式的，但是我身边很多人都喜欢包这么一层，然后什么请求都响应 200，我也就这么做了。 非常好奇为啥大家喜欢这么包一层，是因为业务复杂 http status 不够用才用 code 吗？ 话说这种方案，我实在没想出来有啥大的优点呢……
在成功的响应中加 code 和 message 字段在我看在是无意义行为，只是为了方便调用者使用统一结构进行解析的偷懒行为。
但 data 字段在某些情况是需要在在成功的响应中返回的，因为 oc 不支持解析数组形式的 json 数据…不知道现在是否支持了，除此之外也没有什么必要加 data 字段。
至于 http status code 是否能够代表业务状态，在我看来是不能代表的，它最好只代表 http 请求的状态。因为在客户端提交请求的过程中，各个组件（代理、网关等）都是根据 http status code 来对请求进行处理。
在响应错误时，如果有额外的 message 字段来对错误进行描述，或者增加 code 字段来代表某一类 message，这都是业务需要，与 RESTful 无关。
清一色都返回 200，问题是比较大的
之前帮前端 Debug 就遇到过，打开一个页面发了十几个 request，清一色返回都是 200，但是页面提示报错，还得一个个请求点进去看 response 才知道具体是哪个接口的问题。
然后还有问题就是，如果清一色都是反 200，在一些日志收集服务上，看大盘统计反馈不出业务的服务质量，因为都是 200 状态码。如果改统计规则，改成读取 body 内的 code 来做质量统计，json 又做不到强制格式约束，做不到 100%的格式约束。
比如说 AABBCC 这样六位数的错误代码，可以将错误明确指向到 AA 系统，BB 模块，CC 错误