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

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

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

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

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

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

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

17789 次点击
所在节点    程序员
176 条回复
binux
2022-04-13 12:45:37 +08:00
工作量增大?需要而外配置?区分错误类型怎么办?你看看国内的开发者们都在考虑些什么!

你知道国内 200 一把抓的风气恶心之处在哪吗?
不在于这么做理由,或者说觉得不区分有多好,而是他们根本就不去想理由,麻烦就不去做,别人发布了规范也不去看,闭门造车而洋洋得意。

我很同意 coolshell 里的一个观点,rest API 规范不一定普世,但是人家好歹有成文的规范,也会写这样选择的原因,你可以自由讨论,指出它的问题。你觉得 200 一把抓好,那你见过有那个大厂有成文的规范 guidance 吗?

整天在那讨论政治,说没有参与权,到了真正程序员能有话语权的标准的时候又在那里摆烂,简直就是叶公好龙。
infun
2022-04-13 12:46:35 +08:00
支持 200+post 一把梭
yzbythesea
2022-04-13 12:48:36 +08:00
200 走天下,可是我 grpc 的设计师吗?(狗头

已经被 grpc 的 200 OK 接一个 INTERNAL ,UNAVAILABLE 整怕了。
Biwood
2022-04-13 12:53:56 +08:00
V2EX 不适合严肃的讨论技术,散了吧。我建议去 stackoverflow.com 或者别的什么专业点的技术社区提问。这里是“创意工作者们的社区”,不是技术问答社区。
CEBBCAT
2022-04-13 13:13:17 +08:00
我现在认为 HTTP 状态码是一个副信道,在 payload 之外提供了醒目的消息。比如抓包排障,一屏幕的 200 和 200/4XX ,显然区分了状态码的报文更好阅读
coala
2022-04-13 13:14:09 +08:00
尝试过 RESTFull, 但是没有完全遵守起来, 现在个人的实践,
http code 500 服务器真的内部错误.
http code 401 未授权
http code 200 (业务 code 400 是密码错误这种), 就是业务上的错误,我认为是成功的, 让让前端会有个统一的拦截器去处理业务 code

原则就是 http code 必须保证符合原有的意思, 200 里面再加上业务 code,
但是像是未授权这种, 可能既是业务错误, 也可以理解为 http code 错误 就很头疼

RESTFull 我遇到的问题(Java):
1. 有些内网的防火墙不允许 delete 这种请求进去.. 很让人无语
2. RESTFull 一个 URL 可能对应多个接口, 按照路径配置各种规则的时候 , 日志打印, 就打地址的话看不出调用是那个具体接口, 解决其实也能解决, 日志加上请求的方式, 规则按请求方式 + URL 去配置.
3. 就是理解不明确的, 不知道定义为那种方式的接口
4. Get 传大量查询参数, 不方便的接口, 前端意见很大, 后端接收也不是很方便, 偷懒用 Post 了不少

我觉得 Get 传参限制太多了, 通常只能携带路径参数 (其实理论上服务器也能接收 Get 请求体), 要是能加一种查询的
类似 Get + 能发请求体就好了, 其他的问题都是可以解决,最多麻烦点, 慢慢都会好
fffang
2022-04-13 13:15:32 +08:00
业务错误当然是 200+error ,业务错误是没办法通用定义的,你定义一个我看看。
401,500 当然要用 HTTPCode 。
xuanbg
2022-04-13 13:16:18 +08:00
@adoal 没错,我司也是向来运维和业务两套日志,各管各的真是太简单了有木有。某些人学了点规范什么的就忍不住要拿出来显摆,以此找点自信和优越感,也可以理解的。
seakingii
2022-04-13 13:27:01 +08:00
API 接口返回的状态吗,不用 HTTP 状态码 没有任何问题.

API 接口还不一定用 HTTP 协议传输呢.

纯粹是技术和商业的问题,上面那些从不用 HTTP 状态码,上升到国家,文化,简直搞笑.
haochen2
2022-04-13 13:31:50 +08:00
@daimubai 赞同
horizon
2022-04-13 13:32:54 +08:00
@monkeyWie 飞书系统设计很优秀吗
1000copy
2022-04-13 13:34:58 +08:00
@adoal 赞。
a62527776a
2022-04-13 13:39:31 +08:00
401 指的是接口需要鉴权才能访问
事实上你需要登陆后才能读取数据的接口 不需要登陆也能访问,能理解区别吗?意思是 401 并不是业务层的 code

曾经有个领导 非过来搞这套 烦都烦死了
3dwelcome
2022-04-13 13:42:59 +08:00
我还是喜欢 200 一把梭。

原因是只要遇到 400/500 这种 HTTP 错误状态码,我就马上能知道是 CDN 或者网关之类出问题了,不是我的业务逻辑部分出问题了。

你们可以查一下 RFC7231 设置 200 的初衷( The 200 status code indicates that the request has succeeded ),仅仅代表本次网络请求成功,没有任何别的附加实际业务的含义。所有业务相关的内容,请在 payload 里自己处理。
seakingii
2022-04-13 13:43:31 +08:00
我的建议是面向公众提供的 API 接口,尽量用 restful 规范,大家容易理解,易于标准化.

组织内部或者个人搞的系统,怎么方便就选择哪种
raptor
2022-04-13 13:45:19 +08:00
简单业务当然没什么问题,越省事越好。

但是发展到一定程度就会有问题,比如需要上 API 网关,在其中处理一些如监控,日志,告警,流控之类的时候,本来用 HTTP 动词和状态码可以简单处理的事情,变成需要解析 BODY 的时候,你就准备去填自己挖的坑吧。

当然,如果在可预见的未来,你也不会达到这样的程度,那就随便了——大概率是这样的。
a62527776a
2022-04-13 13:45:34 +08:00
不说 restful 标准什么的
单论用户鉴权相关的 HTTP Status 绝不是 401
binux
2022-04-13 13:48:58 +08:00
@3dwelcome 人家原文明明是“请求成功”,网络两个字是你自己加的。
vayci
2022-04-13 13:49:40 +08:00
每次这个问题都会引发大量争论哈哈哈哈哈
考古贴:《 API 使用 HTTP 状态码还是全部返回 200 》
https://yangjunhui.monster/t/191534
seakingii
2022-04-13 13:56:17 +08:00
楼主想要规范,其实 restful 还有动词的规范:
put ,patch,delete
楼主你想不想用?

用了,有时网络链条中,某些环节对这些动词兼容的不好,
不用,你怎么不遵守规范呢?

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

https://yangjunhui.monster/t/846679

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

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

© 2021 V2EX