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

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

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

27189 次点击
所在节点    程序员
216 条回复
xiangwan
2020-05-29 21:10:01 +08:00
@no1xsyzy
我反驳的是:业务码没用论。
你 5 个 9 也没到 100%,很容易打到其他部分。

错误码就算前端处理不了,显示出来也是有用的,用户把错误码反馈回来后有助于 debug
sanggao
2020-05-29 21:12:54 +08:00
感觉前端小丑就是挺多的,喜欢折腾,又肤浅。像极了文科生
no1xsyzy
2020-05-29 21:29:37 +08:00
@xiangwan #121 “其他问题不存在解决的办法”,至少已经不是返回个 code 能解决的了,大概需要把 Exception 带 traceback 给序列化了。
这种情况应该后端打 error 而不是漏到前端去。遗憾的是,现在似乎不存在哪个 Web App 框架会在报错时将整个运行过程抓取供复盘的,我也没听说过哪个语言的哪个实现能做到这一点,不然那才是正确做法,近乎调试的复盘。
dr1q65MfKFKHnJr6
2020-05-29 21:38:42 +08:00
一般错误用 http code, 业务相关错误用自定义 code. 但是一般代码不规范就喜欢一股脑全整成自定义错误。丑陋无比!
xiangwan
2020-05-29 21:44:48 +08:00
@no1xsyzy 没有说可以*解决*问题,是可以*辅助*解决问题 ,
看下这个场景:错误码 site:https://answers.microsoft.com

“将整个运行过程抓取” ,如果是分布式的怎么办?
现有方案是记录带 request id 的日志
leo108
2020-05-29 21:48:17 +08:00
@kkkwar #92 你是不是以为除了 200 状态码之外其他的状态码就只能返回 Header 而不能返回 Body ?
GBdG6clg2Jy17ua5
2020-05-29 21:50:19 +08:00
我为啥要按 restful 来,不喜欢那玩意
billtsui
2020-05-29 21:50:41 +08:00
不够用,自定义状态码用来返回业务相关的信息。拿注册功能来说,你用 http status code 怎么表示当前账户已存在?
holinhot
2020-05-29 21:54:41 +08:00
没有 responseCode 请问如何跟踪到返回错误的具体执行模块块和代码行
no1xsyzy
2020-05-29 21:57:34 +08:00
@xiangwan #125 啊操作系统问题得用户自己动手解决,虽然操作流程很明确但确实不便直接提示,而采用知识库或者 wiki 的形式贴出解决办法…… 不过是不是贴 wiki 的 URL 会更好?虽然加强了耦合性。
确实比 pacman 出问题每次拿着错误提示去搜索要明确……

不过讨论范畴在 Web API 不是么……

是,目前的方案基本止步于此了,没打 log 的变量是看不到的。或者可能说我其实想要的是一个赋值即打 DEBUG log 带序列化的设施……
nvkou
2020-05-29 22:02:15 +08:00
@muzuiget 发个 options 不就知道接口挂没有了?这种问题老早就解决了
no1xsyzy
2020-05-29 22:02:48 +08:00
@billtsui #128 我于 #108 指出
> 第二,大部分业务错误发生时「客户端(不包括用户)没有任何处理办法」
不需要特地表示当前账户已存在,只需要向前端提示操作失败,给个 404,msg 报 “用户已存在” 就行了。

如果想浪漫点可以 409 Conflict
SilencerL
2020-05-29 22:10:24 +08:00
可是就算 HttpStatus 返回非 200 的时候也可以往 Response 里面塞东西啊...
比如我 HttpStatus 返回 502, Response 里面定义好返回的 message 写原因, 那么没有 message 的就不是业务返回的 502, 而是网关 /CDN/代理等等其他外部原因造成的.
nvkou
2020-05-29 22:26:47 +08:00
这标准出来这么久了,还觉得码不够用难道不是业务设计的粒度问题?
网络传输过程中的错误该不该捕获?网关超时和服务器超时该不该一视同仁?
路由器运营商劫持不就是惯的吗?
HTTP 各种客户端能不能方便的过滤状态码?还是要重复造轮子?
HTTP 各种服务器能不能方便的作日志统计服务质量?还是要保留所有请求原文?
securityCoding
2020-05-29 22:55:00 +08:00
麻烦上面说可以用的多写写代码 , 不要误导人
lllvvv
2020-05-29 23:00:20 +08:00
swim2sun
2020-05-29 23:11:57 +08:00
这帖子让我认识到“国内主流”跟“国际主流” 差别是真的大
skydrive
2020-05-29 23:15:11 +08:00
@securityCoding 入行四五年就可以倚老卖老了?你怎么知道人家代码写得比你少?
dr1q65MfKFKHnJr6
2020-05-29 23:26:53 +08:00
@leo108 422 实体 语法正确,所包含指令无法处理。 字段确实 属于语法错误。
weixiangzhe
2020-05-29 23:27:32 +08:00
以前端角度来说一下,赞成用 http 状态码加 500 错误内自定义 response 里加业务 code 的形式
1. post get delete 本身没有什么区别,但是可以大大方便调式
2. 自定义业务代码当然需要,但是状态码一并处理可以大大的加快前端定位问题的速度, 401 403 和通用错误的 500,在调试工具下一眼就看到了,都是 200 的话需要一个一个点过去看,非常耗时
3. 在非 200 下 response 也能自定义,和你们 200 加 code 区别只是在于状态码不同,当前前端的大部分 ajax 类的库在非 200 时都默认配置了错误捕获,易于前端的通用错误处理
4. 在 200 时有错误 若要配置全局的错误捕获的话的,需要额外配置,又由于每个项目错误的标准不同,自定的 message 之类的位置也不同,每次都要做一次封装处理比较麻烦,又加之在调试面板里不会抛红,调试体验不佳
5. 常用的状态码我看项目里也就 200 400 401 403 404 405 500 502 301 302 之类的加一加心智负担也不重,不确定的码 500 就好, 非错误类型放 200 内加 code 当然也可以

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

https://yangjunhui.monster/t/676678

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

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

© 2021 V2EX