很多人习惯不论接口成功或者失败，接口均返回了状态码200，然后再返回的结果里面再定义具体的业务状态码，例如 status 200 { success: true, data: xxx}。与之对应的是RESTful风格,请求成功的时候(200),直接body返回数据不好么。这里简单分析利弊:
统一返回200状态码的方案:
- 业务状态码是业务状态码、http状态码单独另算
- http状态码表达有限
- 学习成本更低
- 封装略冗余
RESTful:
- 监控系统友好
- 合理利用资源
- 更符合业界规范
笔者强烈认为RESTful风格更加合理、规范，不过需要注意状态码需要合理利用，例如：
- 查询业务数据，查询不到有关数据，状态码必然是200，而不是404
- 滥用的情况，例如原本是非RESTFul的接口设计，鉴权失败返回了401，会导致前端需要特殊处理
- 通用的业务处理：可返回状态码400，并定义具体的错误编码，可参考微信支付-开发者文档 的设计风格
相关参考
我做系统架构的一些原则 | 酷 壳 - CoolShell
API 不管操作成功还是失败都返回 200 状态码，自己在返回结果里又定义一个表示是否成功的属性是从哪里传开的坏习惯？ - V2EX