为什么后端开发都喜欢自己定义 responseCode? HTTP 状态码不够用吗?

2020-05-29 14:10:45 +08:00
 watanuki

所有请求都返回 200,然后自己定义 responseCode, 好像很多大厂的后端接口都是在这样做的,这样做有什么好处? 现在后端开发是不是已经有了关于 responseCode 的统一标准?还是一个公司一套标准? 如果没有统一标准,大家在开发个人的后端项目时也会用 responseCode 吗?

27936 次点击
所在节点    程序员
216 条回复
securityCoding
2020-05-29 23:30:44 +08:00
@skydrive 那你继续用
zouzou
2020-05-29 23:43:48 +08:00
1.http status 统一 200,code 在 http response body 中定义;
2.使用不同的 http status,也有自定义的 response code 。
两种方式各有应用场景,第一种多在单体应用中,前后端协商好怎么处理 http body ;
第二种多在微服务中,api gate 转发 http 请求,有监控系统需要统计请求的相应结果,使用 http status 来表示处理状态。
leon0903
2020-05-29 23:44:49 +08:00
我就想问一句,那些说能用 http status code 的, 你们真的在有一定规模的真实项目中用了么?
ArtIsPatrick
2020-05-30 00:31:06 +08:00
谁和你都返回 200 了,http 状态该返回啥返回啥。比如接口发生异常了,http code 肯定应该是 500,如果换成你自己定义的 code 浏览器是不会识别的。这并不符合 http 协议的规范。
ArtIsPatrick
2020-05-30 00:32:55 +08:00
@guyeu 谁和你都返回 200 了,http 状态该返回啥返回啥。比如接口发生异常了,http code 肯定应该是 500,如果换成你自己定义的 code 浏览器是不会识别的。这并不符合 http 协议的规范。
saberlong
2020-05-30 00:44:11 +08:00
1.写的服务都是部署在内部由你控制。但是由网关或者代理服务出去时不受你管理。你是无法控制他们的处理策略。nginx 默认样例就有对 50x 使用 50x.html 返回。多个团队合作时,会划分错误码。如果使用 httpstatuscode,无法应对团队扩展和业务扩展。
2.服务通信往往不是单单 http 协议。写一个接口,内部框架会转成各种内部 rpc 协议。http 协议进行通信仅仅只是一种。http 的 statuscode 可不是唯一标准。
binux
2020-05-30 00:47:34 +08:00
@ArtIsPatrick #135 随便你返回什么 code,只要是三位数字就可以,浏览器根本就不要求识别未定义的 code,但是 app 可以自行处理。
cz5424
2020-05-30 00:52:03 +08:00
@no1xsyzy 如果是密码错误,需要弹出找回密码框,用相同的错误码,前端用字符串判断吗?
ArtIsPatrick
2020-05-30 00:56:39 +08:00
@binux 是的,然而你返回的是一个别人都没见过的 http code 这有利于对接和排查问题吗?之所以尽量使用 http 协议规定的 http 码是因为这是行业公认的,大家都能够理解。可以快速排查问题。
ArtIsPatrick
2020-05-30 01:00:34 +08:00
@binux 我之所以说浏览器的识别问题,因为能更直观的排查错误,比如在 chrome 的控制台,400 和 500 的错误是会显示成红色的,300 是黄色的。
0dJ6Tu8Za734L89T
2020-05-30 01:04:22 +08:00
@leon0903 我公司组里这边的项目都是用 HTTP Code 的。因为 Google Api Design 里规定好了用什么 code 。错误消息的格式都是固定的:

{
"error": {
"code": 401,
"message": "Request had invalid credentials.",
"status": "UNAUTHENTICATED",
"details": [{
"@type": "type.googleapis.com/google.rpc.RetryInfo",
...
}]
}
}

具体参考: https://cloud.google.com/apis/design/errors

HTTP RPC 说明
200 OK 无错误。
400 INVALID_ARGUMENT 客户端指定了无效参数。如需了解详情,请查看错误消息和错误详细信息。
400 FAILED_PRECONDITION 请求无法在当前系统状态下执行,例如删除非空目录。
400 OUT_OF_RANGE 客户端指定了无效范围。
401 UNAUTHENTICATED 由于 OAuth 令牌丢失、无效或过期,请求未通过身份验证。
403 PERMISSION_DENIED 客户端权限不足。可能的原因包括 OAuth 令牌的覆盖范围不正确、客户端没有权限或者尚未为客户端项目启用 API 。
404 NOT_FOUND 找不到指定的资源,或者请求由于未公开的原因(例如白名单)而被拒绝。
409 ABORTED 并发冲突,例如读取 /修改 /写入冲突。
409 ALREADY_EXISTS 客户端尝试创建的资源已存在。
429 RESOURCE_EXHAUSTED 资源配额不足或达到速率限制。如需了解详情,客户端应该查找 google.rpc.QuotaFailure 错误详细信息。
499 CANCELLED 请求被客户端取消。
500 DATA_LOSS 出现不可恢复的数据丢失或数据损坏。客户端应该向用户报告错误。
500 UNKNOWN 出现未知的服务器错误。通常是服务器错误。
500 INTERNAL 出现内部服务器错误。通常是服务器错误。
501 NOT_IMPLEMENTED API 方法未通过服务器实现。
503 UNAVAILABLE 服务不可用。通常是服务器已关闭。
504 DEADLINE_EXCEEDED 超出请求时限。仅当调用者设置的时限比方法的默认时限短(即请求的时限不足以让服务器处理请求)并且请求未在时限范围内完成时,才会发生这种情况。

例子
HTTP RPC 错误消息示例
400 INVALID_ARGUMENT 请求字段 x.y.z 是 xxx,预期为 [yyy, zzz] 内的一个。
400 FAILED_PRECONDITION 资源 xxx 是非空目录,因此无法删除。
400 OUT_OF_RANGE 参数“age”超出范围 [0,125]。
401 UNAUTHENTICATED 身份验证凭据无效。
403 PERMISSION_DENIED 使用权限“xxx”处理文件“yyy”被拒绝。
404 NOT_FOUND 找不到资源“xxx”。
409 ABORTED 无法锁定资源“xxx”。
409 ALREADY_EXISTS 资源“xxx”已经存在。
429 RESOURCE_EXHAUSTED 超出配额限制“xxx”。
499 CANCELLED 请求被客户端取消。
500 DATA_LOSS 请参阅备注。
500 UNKNOWN 请参阅备注。
500 INTERNAL 请参阅备注。
501 NOT_IMPLEMENTED 方法“xxx”未实现。
503 UNAVAILABLE 请参阅备注。
504 DEADLINE_EXCEEDED 请参阅备注。

以登录和注册为例,用户已经存在(名字,id 重复什么的)就是 409 ALREADY_EXISTS ;密码错误是 401 UNAUTHENTICATED ;找不到这个用户是 404 NOT_FOUND ;
0dJ6Tu8Za734L89T
2020-05-30 01:06:06 +08:00
软件开发当然是自由的,想怎么搞就可以怎么搞,没有最好的方案与设计,大家对软件工程有追求的话还是看看国外大厂是怎么做的。
binux
2020-05-30 01:07:04 +08:00
ArtIsPatrick
2020-05-30 01:08:40 +08:00
@binux 没什么不可以,放 body 里更好,code 加 message 。
0dJ6Tu8Za734L89T
2020-05-30 01:10:10 +08:00
哎我真的是傻逼来回这个月经贴。。。
no1xsyzy
2020-05-30 01:13:46 +08:00
@cz5424 #148 能别提这种经典且彻底的设计失误了吗……
302,Location 带找回密码的地址,再由 JavaScript 作为路由捕获,甚至没了 JavaScript 也能正常运行,符合 PE 。
gadsavesme
2020-05-30 02:30:38 +08:00
协议归协议,业务数据归业务数据,非要合在一起也是无语。快递送到就得了,非得关心我包裹里面是啥东西干嘛?
laike9m
2020-05-30 03:23:20 +08:00
谁让你们用 JSON 而不用 protobuf 呢🤷
nuk
2020-05-30 04:10:38 +08:00
怕通过代理上网的被劫持 404 的客户气的跳起来骂娘
touno
2020-05-30 04:16:11 +08:00
不写 BUG 对不起自己~哈哈哈哈哈

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/676678

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX