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

[h82258652]

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

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

[dreamer1998]

我一般会包一层，因为很多时候会有很多业务异常码，http 状态码显然表示不出来

[AppxLite]

code 是业务代码。以前也不喜欢，觉得没必要。现在感觉也挺好的，感觉规范一点
```javascript
{
code: 200,
msg: "ok",
data: {}
}
```

[Narcissu5]

天哪，登录时不返回详细的报错信息不应该是常识么

[eason1874]

@Narcissu5 #106 这个看你的业务类型，有的业务用户名本身就会作为用户内容的一部分暴露在外面，但就算是去掉这个，也只是把用户不存在的错误改成用户名或密码错误而已，还有大把登录提示。

[beyondye]

程序员都是以为自己比谁都牛逼的一群人

[markgor]

@Narcissu5 我明白你的意思，但是成本的高低是看業務的需求，
當業務是存在此方面的需求，成本就不會覺得高。
當業務對於這方面需求度不高，成本自然覺得高。

但是和你在上面說了三次 無法監控 ，
這真的是有點誤導啊。

你如果說在現有架構上增加監控，那的確如你所說，會消耗性能，並且業務量大的時候會對業務造成困擾。
但是建議你可以了解下旁路設備，增加旁路設備後對數據進行監控，就算業務量再大，頂多就是旁路設備處理存在延時，可監控報表維度一般都按小時 /天 /月 來統計，這點延時根本不足以影響數據準確度；而且旁路設備就算掛了，對業務一點影響都沒有。

另外交換機的端口鏡像，也是實現旁路的一個好設備。

[eason1874]

@Narcissu5 #123 不是常识，是你们想象出来的，说国内的厂商你可能觉得他们知识水平不够高，不信你去登录 Google 或者 Microsoft 看看，用户名不存在他们会提示你不存在。

[Narcissu5]

@markgor 监控不光是看看而已啊，nginx 也好 hystrix 也好这些熔断都是根据 httpcode 来的

[vjnjc]

@fanyingmao #29 哈哈，这个很随意的，要是在定规范的时候你提，或许就变成 0 是 ok，1 是 fail 了。现在规范都定好了

[qwab16]

若是错误处理,我司是 http 500 然后再返回中定义具体错误信息

[markgor]

@Narcissu5 你既然知道熔斷是根據 http code 進行，那你怎麼還主張通過 http code 來代替 response 的 code 呢？
歸根到底就是兩套不一樣的 code，
非要把它們弄到一起，
項目小的話還沒影響，
項目大了的話不就搞到定義模糊嗎？

[hantsy]

@h82258652 你的观点没错。

应该尽可能用 HTTP 语义来描述你的 API （ URI，Method，Status Code ）。

很多人搬出一些国内知名公司的 API 如何如何， 我只能说，那些公司把你们带歪了。

REST API 设计质量评估，可以参见 Richardson Mature Model （ Google 搜索）。从这个角度看，国内知名大公司的 API 绝大部分根本就不是 REST （虽然他们的文档写的是 REST API 指南等），充其量就是用 HTTP 协议而已，看起来和以前 SOAP 一样乱。

如果你想好好设计可用性高，可读性强的 API，参考 Github API，HeroKu，Microsoft 的 API 设计（虽然这个也被 REST 之父骂得狗血淋头，但比国内大公司的设计，不知道甩出几条街）。

[fengci]

不同的错误 code 前端有时候不是还需要做交互操作吗？ 你们有错误就报不做交互的吗？

[linxb]

我也觉得包一层是脱裤子放屁，多此一举，我的做法是，非成功的请求，后端抛出统一的异常，前端如果捕获到异常，直接展示 message 即可，如果没有异常，就直接处理返回的数据

[markgor]

@hantsy
所有的設計指南都是基於理想狀態進行描寫的。
全世界的業務都不是一成不變的，導致不同的公司就算處理相同的業務也存在不同的流程。
這個就類似於 社會主義 和 特色社會主義 的區別。
如果你真要什麼簡潔，那還不如直接逗號替換大法？

菩提本無樹明鏡亦非臺本來無一物何處惹塵埃

[lazyfighter]

我建议采用 http-code，我之前做网关的时候碰到一个项目就是自己包了一层，无论怎么样都是返回 200，但是实际的 code 是 response-body 里面包着呢，导致我们这边的监控基本无用，但是他们自身又很难发现问题，我的经验一般对外 http 服务出问题，最优先会在网关层的 httpcode 以及 rt 时间体现

[hantsy]

@linxb 异常有 Problem API 和 Error API 标准，只是不怎么流行。Spring hateoas 集中了 一种 Error API 标准（自动转化的）。不过最近 Spring hateoas 版本飙升到 1.0，API 变化很大，又需要更新知识了。

[qza1212]

其实核心问题是，你的接口返回的数据类型和结构是否一致

[mikicomo]

@Narcissu5 #49 封装之后怎么不能做监控了...后端主动抛出业务异常日志，包装下返回给前端，然后全链路日志会捕获啊

[markgor]

@lazyfighter
主要問題還是取決於監控粒度的大小。
如果監控內容只是需要成功或失敗,那複用 http code 的確簡單省事。
如果監控內容是需要區分請求成功率和業務執行成功率時，
明顯 http code 無法進行有效區分。

還有，在後端和後端的交互中，
如果遇到 5XX 的錯誤，基本會進行重發請求，
如果是遇到了 200 成功，response code 提示錯誤的，基本不會進行請求重發（具體看 code 的定義）。