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

[h82258652]

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

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

[zhuangzhuang1988]

能用就行, 统一就好

[nisnaker]

@Ianchen #55
我觉得短信 70xx 的代码无任何存在的意义, 用户不关心错误代码是什么, 前端拿到错误代码也不做任务处理
---------------
我觉得所有错误代码无任何存在的意义, 用户不关心错误代码是什么，然后你们前端真牛 x，返回错误啥也不干

[yamedie]

@Ianchen 当然有交互, 比如验证码已失效请重新获取, 吐司的同时自动清空验证码输入框 / 登录已超时请重新登录, 吐司后 3 秒钟自动跳到登录页面就是最常见的交互. 产品经理想给你定义的交互比这些多着呢.

"前端拿到错误代码也不做任务处理, 何必花时间与精力去维护越来越多的错误代码呢?" 凭这句话我能判断你不是一个前端吗?

[yamedie]

@Narcissu5 同 83 楼

[jackchao7432]

@mdluo 那业务场景很复杂,http code 不能较好地描述错误,你怎么办?

[jackchao7432]

@dcsite 这还真不好说,外包从业人员、小公司、学生、zf 部门....估计是这样一个群体

[icris]

@cmobiooo #72
http 404 浏览器会有友好提示页面，不在 code 里写 404 我记得是挺通用的做法

[g1475117007]

我觉得需要，我拿到 code 才能根据 code 内容去做提示或者跳转这类的东西。

[pkoukk]

@Narcissu5 不是很赞成，例如登录失效这种，前端就可以直接处理成自动跳转到登陆页面。而账号 /密码错误就纯吐司提示即可。业务上很多时候不能告诉用户：“你错了”，而是友善的提示用户你该怎么做。这个时候 code 就很重要了

[aa81425600]

笑死我了，你要用不同状态反馈用户不同信息不用 code 字段拿头判断吗？
比如说支付失败，究竟是余额不足还是密码错误，你让前端解析你反馈的 message 然后返回不同的效果吗

[chenxiaohong]

Code 有它实际的业务需求。客户端查询一个资源，HTTP 状态返回 404，这是我 URL 写错了，还是我查询的关键字没有匹配的值？

[passerbytiny]

@h82258652 RESTful 风格要求的是“使用 HTTP 状态码指示接口的执行结果”，并不是“只使用 HTTP 状态码指示结果”，它并不反对你同时使用 HTTP 状态码和数据中的“code”。结果包一层并不违反 RESTful 风格。当然，恒定 HTTP 200，仅使用数据中的“code”表示错误码，这是违反风格的。

一个优良的服务或接口应该在尽量简单的情况下兼容不同的前端，有些前端——比如临时测试并且操作人还懒得打开 F12 的浏览器——可能没有接受 HTTP 状态码的能力，这时候他就需要从返回的 JSON 数据中去获取 HTTP 状态码。一个优良的接口，首先肯定要根据实际情况返回 HTTP 状态码，其次返回内容应该是这样的：
HTTP CODE：NNN
{
"http_code": NNN,
"message": "bula bula",
"main_data":{...}
}
或者是这样的：
HTTP CODE：NNN
{
"http_code": NNN,
"businesslogic_code": NNNNNNN,
"message": "bula bula",
"main_data":{...}
}
第二种情况，如果没有提供 businesslogic_code 的翻译器，businesslogic_code 不管是对前端程序还是对前端的用户来说，都是神秘代码，屁用没有（这个代码，windows 生态中的 800nnnnnxxx 错误代码，是个典型的代表）。在错误反馈中，字符串类型的 message 才是必要的，数字 code 只是可选的。

[broadliyn]

v2 一堆把 restful 奉为圭臬的都是没毕业的学生？？

[Amayadream]

@Narcissu5 #49
1.前端需要关心接口细分的错误类型，从而做配套展示和处理，说不关心可以理解你不是前端也不懂前端。
2.恰恰相反，做业务 code 码封装之后反而更好做监控，监控粒度更细，更容易发现问题。

[newtype0092]

这个问题真好，一下就能分辨出那些人是真的有工作经验的，哪些人是只做过作业、毕设或者个人小玩具的。。。

[HangoX]

http 状态码用来做业务是够用的，410 到 500 之间有 90 的数字，一个接口的状态足够表示了。问题在于中国的网络环境，有些网关，运营商会对非 20x 的返回进行拦截,然后返回自己的数据，这个时候你的接口就得不到正确的信息了。之前有个开发者是分享过这个事情的，被运营商坑成狗。所以我还是建议自己做 code

[passerbytiny]

@icris #79 http 404 的友好返回是：HTTP CODE 404，并且 body 做一个像那么回事的界面。见 https://github.com/bbbbbb/bbbbb，你需要开发者工具才能看到返回的 HTTP 状态码。HTTP 404 只是个状态码，并不表示浏览器遇到 404 就不会继续显示页面；而 HTTP 200 + 404 界面，对浏览器之外的其他前端——比如搜索引擎——可能产生干扰。

[newtype0092]

@mdluo 感谢分享
之前看很多 RESTful 的文章感觉太简单了，只能用在一些“无欲无求”的项目。。。这篇文章里的东西实用多了，不愧 Best Practices

[leopardwei]

定制 600 以上的 code，如果需要的话。包一层的话，好处是觉着清晰了些。弊端是错误码将分 http、业务两种，有些繁琐了，如果对带宽有要求（业务繁忙）也会加大数据量传输。

[so1n]

code 很有用，只是 200 会让你以为是 http code 而已