采取 RESTful 风格的 api 是否应该对结果包一层？

[h82258652]

RT，今天公司的新项目开始对接，app 端的一看我这接口就吐槽我。让我改成如下这种： { "code": 200, "message": "", "data": xxx }

但我觉得首先这 code 肯定是多余的，可以直接从 http 状态码里面读取。之前也看过 twitter 的 api，也没有说包一层，200 的话那就直接返回 data 了。 公司项目我就忍忍算了，毕竟人家老员工。但后面有自己项目的话，还是想弄标准一点。不知道一般来说，大家是怎样实现？

[hoyixi]

又是个没有设计文档的公司

[starerlloll]

code 肯定是要的。。。有的时候业务需求不仅仅是显示 error， 而是根据 code 来显示不同的页面。
你用 error message 来做的话就要疯了。。

[loading]

只要服务器能接到请求我就返回 http 200
业务上的错误我用 code。
例如找不到请求要的东西，我会 http 200 code404

如果用 http 404，不好判断是 url 没写代码处理还是内部逻辑错误了。

[loading]

同时我还带 msg，这是给人看的，一般通用于弹提示框“找不到 xx”

[ericgui]

@loading +1

[eason1874]

借用知乎的名言：先问是不是，再问为什么。

楼主和楼上其中几位别胡扯了，90% 以上正经产品接口都有自己的一套 Error Codes，包括楼主说的 Twitter 在内，不信自己看（ https://developer.twitter.com/en/docs/basics/response-codes ）。

HTTP Status Code 根本不够用，我举个例子，用户登录可能出现的错误包括但不限于账户不存在、账户名或密码错误、验证码错误、账户登录受限（包括各种原因），在程序层面只有 403 Forbidden 那你就只知道登录不了，不知道登录不了的原因，不能根据不同的情况去引导用户进行下一步操作。

[mamahaha]

有规范听规范的，没规范听官大的。

[infra]

楼上说的很对。
包装一层未必就不合适了

[fanyingmao]

@vjnjc 0 一般都是表示成功的，现在接的项目也是 0 失败，1 成功，这种非主流好烦。

[Salvation]

看了楼上一些言论，简直笑了。

首先很多人没有遇到过这种场景，所以有点想当然地表示，http 状态码就够用了。如果在某些场景下，100%够用，并且不用考虑未来的扩展性，那全部人都按照完全 restful 的方式来，也是一种办法。

但是很明显，这种可能性很低。举个最简单例子，一个请求失败了，但是产品上做了优化，针对不同的失败原因，进行不同的展示，请问这个怎么实现，用 http 的状态码一个一个套？很明显这里就需要某些 code 是红色的警告，某些是黄色的警告，某些是个弹窗通知。

归根到底，还是场面见得不够多，并且没有深入思考一些已有方案的内在合理性的结果。

[kanezeng]

我之所以都单独加一层 code，更灵活的表达其实是其次，主要是不想把系统状态和业务状态混在一起

[dotw2x]

用作表示业务状态，没毛病。

[Nasei]

@eason1874 自定义错误码是需要的，但 Twitter 的接口，那些错误码是在 40x 或者 50x 返回的，而且那些码避开了常用 http 状态码的值，但国内很多都是 200 的状态码然后内容里还有一个 200 的 code…甚至所有接口返回 200 只用里面的 code

[h82258652]

@eason1874 我的意思跟楼上 Nasei 的意思一样。在错误情况下，有多种错误而且客户端需求根据错误进行不同操作，那 code 肯定是必要的。但是我主楼的意思是在 200 的情况下，还包一层是真的多余。例如 GET /person/1，有就 200 返回个对象 json，没有就扔个 404 就是了。

[h82258652]

@mdluo 谢谢，收藏了

[justfindu]

我给前端是 200 直接返回 data 数据, 其他错误 返回 message 和 code 格式, 定位错误.

[eason1874]

@Nasei #33 几年前还没普及 HTTPS 的时候，HTTP 接口大多是 200 状态，因为 404 之类的状态会被一些地方运营商和路由器劫持。这种东西只要有个统一规范就行了，既然 HTTP 状态码满足不了需求，统一用数据的状态码无伤大雅。

[xaplux]

肯定要啊，很多情况需要有一套自己的 error code 的，表示一些更细力度的问题，比如下单，下单的时候价格变动，会导致下单失败的，优惠券过期也会导致下单失败，不能都用 400 表示的，那怎么区分是因为价格变动还是优惠券过期导致的下单失败

[ampedee]

@eason1874 你发的链接没看出来和楼主说的有什么冲突。
第一段就写了:
The standard Twitter API returns HTTP status codes in addition to JSON-based error codes and messages.

The Twitter API attempts to return appropriate HTTP status codes for every request.

返回正确的状态码是大前提，只有 error response 才用 code 对具体的错误进行标识，方便客户端查找文档和解决方案。这个 code 换成字符串或者 url 都是可以的，关于 error response 具体可以看看 RFC7808

[yamedie]

{ "code": 7001, "message": "短信验证码已失效", "data": null }
{ "code": 7002, "message": "短信验证码错误", "data": null }
{ "code": 7003, "message": "尚未发送短信验证码", "data": null }
{ "code": 7010, "message": "当前手机号已领取过会员权益，请勿重复领取", "data": null }
{ "code": 9001, "message": "登录已失效，请重新登录", "data": null }
以上报文是我瞎编的，单就一个短信验证码提交接口就有 n 种错误的可能，当（业务上的）错误发生时，data 已经不重要，重要的是 code 和 message，前端依据 code 进行相应的交互，后端也能根据 code 排查异常，message 足够友好的话甚至可以直接吐司给用户，多优雅的设计