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

[h82258652]

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

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

[mdluo]

https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#envelope

[chendy]

讲真，这样设计接口的人，大概是不知道有 http 状态码
类似的道理，还有用参数指定返回格式的人，大概是不知道 Accept 头（可能也不知道 Content-Type
但是，如果真的形成了规范，大家都遵守（最好有现成的代码处理这一层），运行也没问题，那就无所谓了，犯不上为了优雅破坏稳定性

[lihongming]

code 一般不是 http 状态，而是自定义的状态。比如 0 表示无错，客户端只有收到 0 才会去处理 data，否则就去看 errorMessage 了。

[unicloud]

根据我自己的使用经验，这里的 code，显然是偏业务的状态码，而不是 http 状态码；毕竟，在一些复杂的场景，现有的 http 状态码不能完全覆盖或很好的描述当前的业务行为。即便 http code 够用，我也不打算完全依赖它，这是设计原则和标准问题。

[wangyzj]

response:{
responseCode:200，
data:{
"code":0,
"data":[],
"success":true,
"msg":"get data success"
}
}

[wpblank]

自己的应用有一套自己自定义的 code 也未尝不可吧

[mdluo]

Make RESTful REST again, 请。
简单化、（尽力）遵循规范 (Convention) 不好吗，为什么非要加一些不直观、不看文档全靠猜的东西？

[good758]

按规范来。对以后好。

[zgqq]

code 可以用来定位哪些业务，更快排查问题

[ke1e]

一般会包装，参考微信公共 api 的返回结构

[xh520630]

公司可以有一套自己的 code。非要说大公司的话，绝大多数的大公司都有一大批错误 code
随便贴一个 https://developers.weixin.qq.com/doc/offiaccount/Getting_Started/Global_Return_Code.html
200 只是人习惯用的没啥不行有的人就喜欢 0 表示 ojbk。

[ericgui]

你的前端没问题

你要学会换位思考

同一个问题，解决思路很多，而且无所谓对错，是“范式”不同

[good758]

code 在匹配时很有用，调用时别人一下就可以快速做判断错误 http 状态最容易欺骗人
数字是最没的多音字不容易出错的的符号
成功还好，失败 应该怎么判断错误原因呢并做操作呢。不是一样又要一个错误规范吗，人来读吗

[airyland]

code 是需要的，尤其是不同错误在前端需要做不同处理时。错误文案可能会变，根据 code 作处理才是正确的。

[hakono]

没什么好吐槽的，真的
楼主觉得靠个 http status 就能解决掉状态码，是没遇到过要返回 N 多不同的错误的情况。当一个 api 或者系统需求复杂起来，区区的 http status 根本不够用。表示错误的状态码就那几个，但你业务的错误逻辑有十几个几十个，这时候你最后就会自然用起 { "code": xxxxx, "message": "" } 了，这时候是不是得感叹下自己活成了最讨厌的样子。。。

RESTful 说到底也不过是个风格，并非限制死的东西，实际业务需求的复杂是根本无法靠一个 RESTful 全部解决的（虽说 RESTful 是适用资源类的 api，但有时候你资源类 api 的业务逻辑也能复杂的一批）

[ochatokori]

赞成需要 code
restful 风格可以参考，完全实施有点不符合实际
不常用的 http 状态码可能会在奇葩浏览器上有奇葩默认行为

[version]

加 code 是没错的，这个是自定义业务的错误码，原则上全部接口都是 200 状态码，而且最好是换个单词，减少其它语言关键字的问题
标准是标准，但也存在弊端，接第三方 api 就明白，大部分国内都是走业务 code 状态码，国外比较多走 restful，不过对于细到具体业务错误来说，捕获 http 全局不太好丢回给子模块，对于接收人来说比较累

[helone]

我个人实践中比较喜欢 restful，2xx 代表成功 常用 200 201 204 4xx 客户端 5xx 服务端，完全够用

自己业务想抛个自己的错误记个日志不行吗？客户端只需要知道错误的 message 就行了

说自己业务复杂 http code 不够用的我是服了的，那你一个页面几百个字段，随便缺一个就留一个 code 这谁顶得住，就不能用 errors 描述下吗？

[vjnjc]

肯定是要的。只是他数值正好是 200 让你很不爽，比如我设计的就简单了，0 访问失败，1 访问成功，2 ～ 99 各不相同。

[nvkou]

跟着行业标准走。自己再搞状态码只会让人不断吐槽。
合着搞半天我还要区分协议状态和业务状态？那后面是不是还要把 encode types, cache control, authorization 这些也再写进业务？好好的工具包不用，非得造轮子