为什么要区分不同的 http 状态码?想说服同事

2022-04-13 10:28:42 +08:00
 dunhanson

我的个人的理解还是,这么做比较规范

但是同事的理解更多是优点好处是什么

比如用户登录错误之前的方式都是返回 http 状态码 200

{
  "code":4001001001,
  "message":"用户登录失败"
}

现在按照规范应该是,返回 http 状态码 401 ,然后 json 还是老样子

17789 次点击
所在节点    程序员
176 条回复
wu67
2022-04-13 14:58:39 +08:00
月经帖....
目前一种比较常见的方法, 是 http code 管 http 请求状态; json 里面的 code, 管该请求的业务状态, 两个别混作一谈.

就目前国内应用乱七八糟的业务场景而言, http 状态码的使用, 很难覆盖到大部分场景, 那还不如直接 http200 一把梭, 靠业务 code 区分, 其他非 http200, 前端全部当成出错处理
sjdhome
2022-04-13 15:01:40 +08:00
只用 200 然后自己定义状态码无非是把 HTTP 当成传输层协议来用了,然后自己发明一套应用层协议。如果真有自己定义的必要那就直接重新定义新的应用层协议好了,别用 HTTP 套娃了。
TimPeake
2022-04-13 15:09:42 +08:00
散了吧 引战贴🤣
Chad0000
2022-04-13 15:09:55 +08:00
@sjdhome
严格遵守必有所失。比如下单前检查是否能下,是不是应该使用 get ?那么多参数对象数组嵌套你非用 get 折腾?某些场景允许 404 ,你非给我返回错误码,一堆可以接受的 404 不会给运维带来麻烦?

http 传输层错误和业务层错误分开,有那么不堪一击吗?
iyaozhen
2022-04-13 15:17:04 +08:00
@3dwelcome 监控是全方面的

你说的单独写 API 是探针那种?
业务上来说一般是日志监控(已有关键字、新增错误等等方式),还有自动化拨测
iyaozhen
2022-04-13 15:20:25 +08:00
@adoal 哦哦,那认同你的观点。「为了方便监控离校系统调用图书馆系统接口时的业务逻辑错误率而想把我千奇百怪的业务错误码从 JSON 里提出来放到 HTTP 状态码吧。」这种是不支持的
这种就是业务自己日志监控或者埋点上报了
xuanbg
2022-04-13 15:50:26 +08:00
@sjdhome HTTP 是 HyperText Transfer Protocol 的缩写,翻译过来就是超文本传输协议,本来就是传输协议,怎么就不能当传输协议用?
dunhanson
2022-04-13 15:52:03 +08:00
@ClericPy 确实,无论如何,统一比较重要
lshero
2022-04-13 15:56:47 +08:00
我觉得最好还是提前沟通一下
因为接口的改动涉及的上下游不只自己一人,也许客户端不想在异常捕获里处理业务逻辑。
也许运维团队就想监控一下 status code ,判断一下服务是否正常,压根不关心你的业务逻辑对不对
stroh
2022-04-13 15:58:19 +08:00
说个地狱笑话:老板没给超过 post 返回 200 多余的工资
----来自一位曾经月薪 30k 的同事
yedanten
2022-04-13 16:09:10 +08:00
业务层返回的状态码一律 200 ,这才符合规范好吧,不然因为授权失败返回 401 到底是业务层出的问题还是 nginx 之类的 web 服务器配置问题亦或者是路由网关层拦截?而且按规范,你业务层都处理玩业务逻辑了,就是说明请求的资源是存在并且有业务处理结果了,当然是 200 啊
Nich0la5
2022-04-13 16:19:42 +08:00
以前因为用 40x 导致 nginx 误以为宕机,后来就干脆全 200 了
fkdog
2022-04-13 16:23:01 +08:00
其实原因在与,以前的 http 是用来传输超文本一类的资源的。现在应用复杂化,http 职责下沉,用来当成数据的封包协议。
很多大公司甚至连 location 都不用了,把服务名当成参数丢进 request body 交由后端路由。

陈皓的文章我看过,我觉得他说的也有道理。但是想想陈皓他本身是一个优秀的开发者,与他共事的人肯定也是很优秀。因此他很难想象在一些小公司里,水平良莠不齐的开发的想法是有多奇葩。国内的开发人员普遍缺乏工匠素养,外加国内的氛围就是抢用户市场、赚快钱,因此稳定的架构、夯实的基础并没有太多的价值。

我觉得,人应该灵活一点。面对水平低的同时,你花时间去和他 argue & debate 没有意义,不如直接是是是,能忍则忍,不能忍直接润。
bobo2
2022-04-13 16:25:32 +08:00
都返回 200 ,错误日志不就不存在了??那出问题怎么查日志?
EastLord
2022-04-13 16:33:58 +08:00
@yedanten 哪里有状态码一律 200 的规范,学习一下
lmmlwen
2022-04-13 16:41:18 +08:00
我看这里面一堆理论家,说状态码这好那好,但有人用吗,估计很少,因为会造成诸多不便,基本都是理论式编程
byte10
2022-04-13 16:43:37 +08:00
@Biwood 哈哈 用 404 劫持页面,这个鸡贼😂
@adoal 可以的 666 ,收录你的回答,以后可以用这个理由。
@BeautifulSoap 同意。
@1000copy 挺好的,收录你这些理由。
@alswl 同意,收录,单纯把 http 当做传输协议也未尝不可,尤其是在 app 端是更好了。
@adoal 挺好的分析
@MrSheng 😂,可以的。
@salmon5 真实了。
@3dwelcome 可以的,案例不错。
@lisongeee 哈哈跨界了
@coala restful 规范确实很难执行
@seakingii 我不喜欢 restful ,都是太过于理想了。

总结一下:业务服务还是 200 一把梭好,没有啥原因,把 http 当成一个传输协议,因为有可能用 mqtt ,也可能用 ws 。听话不然就会很惨的,以后会很惨,前端后端都惨。跟那个 restful 一样,最后四不像。还是把事情简单化吧,不然以后不会幸福的。
casxter
2022-04-13 16:43:50 +08:00
其实这是个公司历史遗留问题,公司用啥就用啥
mydingyan
2022-04-13 16:43:52 +08:00
@zmal 点进去看看误打误撞竟是左耳朵耗子的博客,前几天通过 Qecon 看他的直播
skiy
2022-04-13 16:51:22 +08:00
因为状态码不够用?毕竟只取状态码无法判断是什么错误。

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

https://yangjunhui.monster/t/846679

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

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

© 2021 V2EX