请问下，接口访问返回码这个东西。有一般定义的习惯吗？

[ukipoi]

还是全看自己心情定义？
老板和我说了小程序的需求，就让我一个人负责后台。
我好像看到一般成功的返回码是 0。
那其他的错误码怎么设计好。
接口访问失败，返回的错误码是要能区分 操作数据库失败还是空值 这种具体内容还是笼统的划分一下就行了？
如果要给错误码分类的话，怎么进行分类比较好？

[EvilCult]

我一般是这样:
定义个 json(或者随便其他什么格式),大概结构是
{
'10': { # 对应用户大类,比如‘ 10 ’对应用户
'01': { # 对应具体功能,比如‘ 01 ’对应登录
'01': '用户名不能为空',
'02': '密码不能为空',
'03': '用户名不存在',
.......
'99': 'xxxxxx',
},
'02': { # ‘ 02 ’对应签到
'01': '今日已经签到',
'02': 'xxxxxx',
.......
'99': 'xxxxxx',
},
..........
'99': {
'01': 'xxxxxx',
.......
'99': 'xxxxxx',
}
},
'11': {# 比如‘ 11 ’对应文章
'01': { # 比如‘ 01 ’对应访问
'01': '对未登录用户开放',
.......
'99': 'xxxxxx',
},
........
}
}


然后比如用户登录的时候瞎填了个不存在的用户名,直接返回错误码「 100103 」,
客户端拆分错误码 [10], [01], [03] 就知道是什么错误了.

[mokeyjay]

一般用 HTTP 状态码就行了吧，比较特殊的错误才用自己的错误码
可以按照模块划分，比如 10xxxx 表示用户模块、11xxxx 表示购物车模块之类的，以此类推

[pynix]

http 状态吗，有问题一律 400

[CFO]

有返回码还得有个对应表 到时候你会发现后端不知道改返回哪个 前端拿到后不知所措

[superlks]

业务比较复杂，http 状态码没办法描述问题，自然需要自己定义。这个你和后端协商一下吧，你们自己能看到就行

[lucahan]

你如果自己干，那当然不需要。但是如果前后端分离的话，状态码是必须的啊。我和 1 楼用的差不多

[wolfie]

简单的 1、0。
碰到过 成功: 200，找不到: 404，失败: 400 的奇葩玩意。