code: 定义错误码
msg:“xxx error”
code: 5000
msg:"xxx 错误,请检查 xxx"
除了 msg 内少写一些内容,还有别的优劣吗?
1
opengps 2023-09-05 15:41:02 +08:00
code 是给程序用的,可以自己扩展写分支处理逻辑
msg 是给人看的,可以友好提示文本(这里不得不吐槽,很多程序没处理到友好的程度) |
2
mdn 2023-09-05 16:01:38 +08:00
code 是给前端看的
msg 是给用户看的 |
3
k9982874 2023-09-05 16:05:59 +08:00
你只给个 msg 让前端做根据错误跳转页面,你看前端喷 不喷你
|
4
fimd 2023-09-05 16:30:40 +08:00
我这么多年来,接口一直来都是按这格式返回:
code: Success/Error/Empty msg: 这是具体的文字提示 item: 这是业务信息内容 ----------------- 大家提意见吧,欢迎拍砖 |
5
IvanLi127 2023-09-05 16:44:44 +08:00 1
我觉得
code 是给程序看的 msg 是给开发看的,要言简意赅 用户看的错误信息是前端自己结合 code 以及额外的错误信息给的友好提示 |
6
kaedeair 2023-09-05 16:53:43 +08:00
code 处理逻辑,msg 弹窗告诉用户,有 msg 定位错误快一些
|
7
oppoic 2023-09-05 18:01:00 +08:00
{"code":200,"msg":"操作成功"}
绿框提示 “操作成功”,并进行下一步(比如刷新页面) {"code":403,"msg":"请先勾选再提交"} 红框提示 “请先勾选再提交”,页面保持不动 {"code":500,"msg":"未将对象引用到实例"} 红框提示 “网络异常,请稍后再试”,页面保持不动 403 和 500 的区别是:403 是逻辑错误,500 是后端抛错了,程序抛错信息不给用户看,让用户看友好提示,程序员按 12 可以看到,也可以去库里查更详细的抛错日志 |
8
mdn 2023-09-05 18:12:06 +08:00
|
9
chendy 2023-09-05 18:24:54 +08:00
有编码规则的字符串错误码,比如 模块_功能_编号 这样
纯数字的存起来能省点空间,但是实在算不上友好 |
10
cnoder 2023-09-05 18:36:25 +08:00
不能都返回吗
|
11
index90 2023-09-05 18:40:29 +08:00
|
12
nikenidage1 2023-09-05 18:44:01 +08:00
日经话题了
个人推荐就是使用 http status code ,然后如果更详细的错误,也有 rfc 的规范可以标准化 https://www.baeldung.com/rest-api-error-handling-best-practices https://blog.axway.com/learning-center/apis/api-design/introduction-to-rfc-7807 |
13
NoKey 2023-09-05 18:47:05 +08:00
有个争议,到底用 http 的 code 还是自己的 code ,这个目前还未分出胜负😁
如果使用自己的 code ,那么 code ,msg ,data (实际数据体),这 3 个参数一般都是同时出现,到底给谁的不在意,前端可以根据 code 来快速判定执行是否成功,如果执行失败,那么 msg 就是提示了,很多提示前端不不好去匹配的,后端直接给了就行 |
14
flyqie 2023-09-05 18:48:17 +08:00 via Android
{"code":1,"msg":"未知错误","data":{...业务数据}}
|
15
IvanLi127 2023-09-05 19:41:21 +08:00 via Android
@mdn
生产环境和 msg 大概就是一个 code 对应一两种 msg 文本,不想暴露的内容可以在程序里判断环境去输出,比如我负责的项目的登录结果,开发环境是具体说因为什么原因导致哪个环节登录出错,但是生产环境就的 msg 就只说“账号密码不匹配”和“账户锁定”。 表单的错误信息,比如 xx 字段不满足 xx 条件,这个信息是扩展的错误信息,扩展的错误信息可以是对象,能结构化地读取具体错误出来。msg 只是一个字符串,除非前端嗝屁了,不然这个信息不应该直接透传到 ui 上。 |
16
Nazz 2023-09-05 19:45:24 +08:00 via Android
我全都要
|
17
lanweizhujiao 2023-09-05 19:49:39 +08:00
接口返回错误码和消息(通常是一个简短的文本描述)是常见的做法,用于传达接口操作的结果和可能的错误信息。它们各自有一些优劣势,下面是它们的主要优点和缺点:
错误码( Error Code )的优势: 标准化和规范性: 错误码是一种标准化的方式来表示不同类型的错误。每个错误都有一个唯一的错误码,这有助于在不同的应用程序和系统之间实现一致性。 机器可读性: 错误码通常是数字或字符串,易于在程序中进行比较和处理。这使得自动化处理错误变得更容易,例如,根据错误码采取特定的恢复措施。 多语言支持: 错误码不依赖于语言,因此可以轻松地实现多语言支持,只需根据错误码查找相应的错误消息翻译。 性能: 错误码通常比文本消息更轻量,所以在网络传输和存储方面具有一定的性能优势。 错误码的劣势: 不直观: 错误码通常不直观,不容易理解。开发者可能需要查阅文档来了解每个错误码的含义,这可能会增加开发和调试的复杂性。 用户不友好: 对于最终用户来说,错误码通常不是一个友好的方式来了解问题,因为它们缺乏描述性的信息。 |
18
lanweizhujiao 2023-09-05 19:50:28 +08:00
6666666666
|
19
MFWT 2023-09-05 19:54:42 +08:00
个人写的很简单的小项目,最后采取的是 code+msg
code 为 1 就成功,0 就失败 具体发生什么事了,写在 msg 显示出来里让用户处理,比如『用户名密码错误』,『请输入有效金额( 0-200 )』 不知道有没有什么坏处? |
20
scegg 2023-09-05 19:57:07 +08:00
code 比较好实现国际化。
不然要在后端提供本地化语言描述,导致两端都要处理语言。 |
21
lanweizhujiao 2023-09-05 19:59:25 +08:00
@mdn 文档
|
22
xuanbg 2023-09-05 22:26:37 +08:00
code 是用来处理不同分支逻辑用的,message 是抛出来给人看的。所以 code 定义有限的几个就行,message 要在抛出异常的地方定义。
|
23
Orlion 2023-09-06 09:15:12 +08:00
code: 方便排查问题,根据用户返回的 code 找到问题发生地
msg: 出现了问题,告知用户发生了什么以及如何解决 |
24
liuidetmks 2023-09-06 11:05:30 +08:00 1
@MFWT 一般 0 是成功,非 0 是失败
|