有严格遵守 RESTful 范式的朋友吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1350 天前的主题，其中的信息可能已经有所发展或是发生改变。

很多人，接口设计都是纯 200，然后 BODY 类似：

{
  "code":0,
  "message":"",
  "data":null

URL 类似：

/user?id=1

这样。刚开始我也试图遵守 RESTful 范式的，但是我身边很多人都喜欢包这么一层，然后什么请求都响应 200，我也就这么做了。非常好奇为啥大家喜欢这么包一层，是因为业务复杂 http status 不够用才用 code 吗？话说这种方案，我实在没想出来有啥大的优点呢……

RESTful

范式

Code

遵守

17 条回复 • 2021-04-16 13:44:33 +08:00

mhycy

2021-04-15 10:48:46 +08:00

非 200 状态码可能会被浏览器 or 网关拦截

kkkkkrua

2021-04-15 11:00:48 +08:00

可以搞，但是不要照本宣科，有些复杂的场景 RESTful 也没办法表示其意思

baiyi

2021-04-15 11:00:55 +08:00

RESTful 没有一个标准范式，只有各大厂商的实践规范，所以也谈不上遵守。

在成功的响应中加 code 和 message 字段在我看在是无意义行为，只是为了方便调用者使用统一结构进行解析的偷懒行为。
但 data 字段在某些情况是需要在在成功的响应中返回的，因为 oc 不支持解析数组形式的 json 数据...不知道现在是否支持了，除此之外也没有什么必要加 data 字段。

至于 http status code 是否能够代表业务状态，在我看来是不能代表的，它最好只代表 http 请求的状态。因为在客户端提交请求的过程中，各个组件（代理、网关等）都是根据 http status code 来对请求进行处理。

在响应错误时，如果有额外的 message 字段来对错误进行描述，或者增加 code 字段来代表某一类 message，这都是业务需要，与 RESTful 无关。

abersheeran

2021-04-15 11:16:20 +08:00

可能是因为以前的项目都是这么封装的，有许多现成的代码。没有影响业务的情况下，就不改了。

MiniGhost

2021-04-15 11:31:04 +08:00

非 200 被拦截这一点，现在满大街都是 HTTPS 了，已经没有这个问题了

清一色都返回 200，问题是比较大的

之前帮前端 Debug 就遇到过，打开一个页面发了十几个 request，清一色返回都是 200，但是页面提示报错，还得一个个请求点进去看 response 才知道具体是哪个接口的问题。

然后还有问题就是，如果清一色都是反 200，在一些日志收集服务上，看大盘统计反馈不出业务的服务质量，因为都是 200 状态码。如果改统计规则，改成读取 body 内的 code 来做质量统计，json 又做不到强制格式约束，做不到 100%的格式约束。

IvanLi127

2021-04-15 12:40:40 +08:00 via Android

自己的项目就严格遵守，公司的只能跟着大家的写法写了。遵守起来是可行的，不过有些地方不变通，其实也不太好。
响应包一层就很无语了，异常处理流程能是正常流程一样么，包一层也做不到复用，还浪费

wangkun025

2021-04-15 12:45:24 +08:00

用的是 Ruby on Rails，写 API 的时候，尽量使用状态码。但有的同事喜欢在 body 里写状态码，然后全部用 post 。

lsdvincent

2021-04-15 13:29:49 +08:00

还真有，但是有时候会被说有点繁琐，太严格了

timethinker

2021-04-15 13:52:21 +08:00

的确是有很多公司用统一的包装体来返回所有的数据，我个人认为这是没有必要的。
首先，在成功的情况下，code 和 message 是没有意义的，前端也只会取里面的 body 字段。
其次，在失败的情况下，body 字段一般都为 null 。
就先前面几位说的，如果在失败的情况下不使用 HTTP 4XX 状态码，而全部使用 200，对外部的监控 /采集系统来说也确实不太标准。
所以这个包装体在成功或者失败的情况下都存在冗余字段。
我们目前对于成功的请求（ 2XX ），只返回数据本身，不同的接口直接返回不同的数据。
失败的情况下才会返回统一的错误数据结构，比如 code 、message 。