主管想用的接口输出
{
"status" : "错误码"，
"error" : "错误消息"，
......
}
楼主想用的接口输出
{
"errorCode": "错误码"，
"errorMsg" : "错误消息"，
......
}
我在想一个接口至于争吵一天吗？最后我妥协了，现在感觉好想离职，请问怎么破
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2643 days ago, the information mentioned may be changed or developed.
Supplement 1 · Mar 20, 2019
首先非常感谢各位社友的回复和讨论，在看各位社友的评论中学到了很多东西，果然三人行必有我师焉！
-
社区有些社友可能认为这种接口争吵没啥意义，随便定义一个就行，但如果这个接口被几千人使用甚至被几万人使用，那就得对这个接口好好设计了。如果连自己都对自己提供的接口不保持敬畏，那就别指望用户对你提供的接口保持敬畏，对于用户的抱怨牢骚那只能全部接下。过去几年里很多用户对我们提供的接口出现过各种各样的抱怨（每个用户都有一套自己心目中的接口，就像社区内留言出现很多接口定义），如果接口提供方的接口与接口使用方心目中的接口不一样就会出现或多或少有抱怨和吐槽。为了尽量让用户用的爽，减少用户的抱怨，所以就和主管对接口进行了争吵（善意的争吵），至于想离职是其它方面的原因；
-
有些社友可能认为和主管争吵不太好，主管想做成什么样自己就做成什么样。但你真认为这种状态好吗？即使你照做了，你觉得主管认可你吗？在互联网环境下，得多与主管、同事讨论讨论问题，有些难解的问题就是在讨论中产出解决方案的。过去几年和主管同事争吵过无数次甚至拍桌子，差点打起来，但这种都是idea的碰撞，只有碰撞中才能产出好的idea，其实碰撞完后同事主管都会私下交流这个都是各自想法，不代表其他含义，不要往心里去。对于主管要你做啥你就做啥，那主管招你有何用，主管可以招任何一个人来替换你，这样你的自身竞争力在哪里。一个程序员要往高处发展，要学会自己去发现问题去解决问题，而不是等待主管安排问题，比如主管交给你一个手工线上部署任务（需要经常部署），结果你每次都可以手工无故障的部署完成，但这种结果是主管希望的吗，主管再找一个人也可以无故障的手工部署，但如果你把手工线上部署做成自动化工具一键部署，可以节约时间且无风险，这样在主管看来你就是不可替代，能自己对问题提出解决方案；
-
程序之美应该包含编程之美、接口之美和测试之美。如果有一段程序编程无规范、接口随便定义，无单测和功能测试，让你去接手这段代码，你会怎么想？所以还是对接口保持敬畏之心，多花点时间定义接口，少花点时间答疑和听用户的抱怨；
下面各出了很多社友的接口定义，可以供借鉴，排名不分先后，可以投票😄
{
"code": "错误码",
"message": "错误消息"
}
{
"errno" : "错误码"，
"message" : "错误消息"
}
{
"status": "错误码",
"error": "错误消息"
}
{
"status": "错误码",
"msg": "错误消息"
}
{
"errKey": "错误码",
"errMsg": "错误消息"
}
{
"status": "错误码",
"error": "错误消息",
"errorCode": "错误码",
"errorMsg": "错误消息"
}
{
"statusCode": "错误码",
"statusMsg": "错误消息"
}
{
"error_code": "错误码",
"error_msg": "错误消息"
}
 |
101
GeruzoniAnsasu Mar 19, 2019 via Android  3
我感觉诸位也能在这个帖子里吵一天。。。
|
 |
102
Heavytiger Mar 19, 2019
怎么不用下划线:error_code
|
 |
103
vimiix Mar 19, 2019 1
我觉得主管的更通用一些，code 可以兼容其他情况，并不一定都是 error 情况。
|
 |
104
yiyi11 Mar 19, 2019 via Android 7
下属唔可以啵上司嘴。
|
 |
105
wingspread Mar 19, 2019
钻牛角尖
|
|
106
wingspread Mar 19, 2019 1
建议辞职。
|
|
107
yiyi11 Mar 19, 2019 via Android
多喝热水，喜欢就买，不行就分，遵循自己的内心。
|
 |
108
zwh2698 Mar 19, 2019 via Android
其实更建议将 error， 修改为 message.还有 json 不要用驼峰命名，全小写。因为有些语言对大写解析会出错。小写都没有问题
|
 |
109
ben1024 Mar 19, 2019
"一个接口至于争吵一天吗?"，直接安装你主管的来
不开心就内部用自己的，外部封装一层输出层 |
 |
110
hahaayaoyaoyao Mar 19, 2019 via Android
@keepeye 这种是最好的
|
 |
111
karllynn Mar 19, 2019 1
支持主管
这种只是风格问题的设计，你居然不听领导的，我觉得你在哪都干不下去。 |
 |
112
zzzzzzZ Mar 19, 2019
果然大部分用的都是这种：
{ "code"：0， "msg"：null， "data"：{}， } |
 |
113
longxboy Mar 19, 2019
这就是一个风格，没有谁对谁错，定下一个标准就行
|
 |
114
jrient Mar 19, 2019
{
"status":0, "msg":'' } |
 |
115
StarRED Mar 19, 2019 via Android 1
主管是背锅的，要听他的。
|
 |
116
az422 Mar 19, 2019 via Android
闲的蛋疼，从楼主示例来说，两种方案功能是一样的，就是命名不同而已，这也能吵我服了
|
 |
117
Lonely Mar 19, 2019 via iPhone
@struggle001 你是认真的还是搞笑的
|
 |
118
udumbara Mar 19, 2019 2
庆幸自己没有和这样的人（楼主和主管）共事
|
 |
119
akatquas Mar 19, 2019 via iPhone
@raysonx There are only three hard things in Computer Science: cache invalidation and naming things.
|
 |
120
fanhaipeng0403 Mar 19, 2019
吵这个有意思吗
|
 |
121
netstu Mar 19, 2019
这种问题明明是楼主的问题，较真，不服气
我要是有这样的下属真想干掉，带着累 我的理由是：这根本不是什么大问题，如果真是主管有问题，那可以较真，但这明显不是 |
 |
123
auh Mar 19, 2019
有分歧很正常，不过我看第一种没毛病。
|
 |
124
st2udio Mar 19, 2019
{
"code": 0, "data": null, "msg": null } 难道这么多年我写错了? 非要选，我支持主管那种。 还有，这种东西，争吵一天？ |
 |
125
wfd0807 Mar 19, 2019
你应该离职，我支持你
|
 |
126
focusheart Mar 19, 2019
{ 'error': true, 'err01': true, 'err99': false, ...} 还有这种错误码呢……万一遇到了岂不是要吵 99 天……
没多大事儿，看开些~ |
 |
127
donyee Mar 19, 2019
我推荐是
{ "result_ode": "返回码"， "result_msg" : "返回消息"， ...... } |
 |
128
abcbuzhiming Mar 19, 2019
首先主管是背锅的，你不能因为要坚持你的理念，就把责任扔给别人，坚持理念者要付出应该的代价。其次，你有离职的自由，强烈建议你换个地方，自己当主管
|
 |
129
fxxkgw Mar 19, 2019
首先如果是 python 你这样肯定不行吧。。
|
 |
130
dxgfalcongbit Mar 19, 2019 via Android
每个人的想法不一样很正常，所以需要有个拍板的。
|
 |
131
nihonngo Mar 19, 2019
这有啥吵架的，不用上班啊
|
 |
132
lhstock Mar 19, 2019
（此处只说命名，不提结构）支持主管。首先。其实用什么都无伤大雅。如果说易懂按照不同规范来看，”易懂“本身就是不确定的，所以随便用。那么为什么要统一。比如 ABC 三人三种习惯，这很常见，当然谁都没用错（不引战），没有规范，格式必然五花八门。那么 debug 的时候就会很痛苦了，因此有了需求：把习惯”统一“。最终只是有了一道选择题而已。可能 1：相对而言你不具有选择权。2：这个选项早已选好。最后：规范这种东西有人有能力定制一定程度上说明了公司的底蕴。毕竟大部分公司没用这种东西。羡慕
|
 |
133
dany813 Mar 19, 2019
笑哭
|
 |
134
TheWalkingDead Mar 19, 2019
code
data message |
 |
136
ericgui Mar 19, 2019
领导估计都想让你离职了
你搞笑呢吧，这个破事都能吵架，到底谁是老大？ |
 |
137
simple2025 Mar 19, 2019
直接按照 http 的 status 和 message
|
 |
138
NotFamous Mar 19, 2019
这都算好了，跟我搭档的后台，，，英文单词经常拼错，然后光是“ ID ”这个字段就有好几种字段名：ID、Id、id，一点规范都没有
|
 |
139
webjin1 Mar 19, 2019 via Android 2
{
"cuowudaima": "错误代码"， "cuowuxiaoxi" : "错误消息"， ...... } 我觉得这样好 |
 |
140
arsenal4 Mar 19, 2019 1
主管唯一的错误就是为什么不在吵到半天的时候还不把你开掉
|
 |
141
hayvane Mar 19, 2019 via iPhone
说实话，都不好！非要二选一那肯定是选主管的，原因楼上有人分析了。这都能吵一天，我是主管早让你滚蛋了！
|
 |
142
index90 Mar 19, 2019
楼主是一个刚进 BAT 的毕业生，太嫩了。
回到楼主的问题，该不该离职。 如果你认识到自己的问题，建议你请主管喝杯咖啡，虚心学习。 如果你依然觉得自己是对的，BAT 不是你的平台，那就离职出外面去看看。 |
 |
143
flyingghost Mar 19, 2019
请把字段的可选、必选确定一下。
方案 1： status/code，必选字段，为 0 表示正常，为其他表示异常。（留扩展空间，比如正常 /异常二元值之外的其他定义。http 的 status 用分段来表达很多不是错误的状态） error，可选，如果 status 标识为错误的话，提供详细信息。 方案 2： errorCode，可选还是必选？ 如果可选，那就意味着用存在 /不存在来表达是否出错。一般不这么做，而且存在 /不存在是二元选项，无法扩展。 如果必选，=0 表示无错？ 一有冗余之嫌，相比可选方案，浪费流量。 二有歧义之嫌。我按"error"搜日志居然能搜出一堆正常数据？ 三引入隐含信息。0 表示没有那-1 和+1 表示什么？凭什么 0 隐含默认公认功能？需不需要额外普及和记忆？ 其实以上都是废话，讨论来讨论去谁也说服不了谁。最根本的问题：你是决策人和责任人吗？凭什么和老大吵？ 任何一件事我们都鼓励积极参与积极建言，但任何一件事都有最终决策人和对决策负责并承担一切后果的人。责任明确也是分工和分等级的意义之一。你可以花 5 分钟跟老大建议并探讨，然后花剩下的 7 小时 55 分钟带着怨气或者绝望把你俩的共识给落地实现，也可以花剩下的 7 小时 55 分钟仔细考虑什么时候跳槽去离开这个傻逼或者给老大的老大提出这个人不适合领导并决策。但你是凭什么花 7 小时 55 分钟针对这个问题和老大去吵一天的？ How dare you! |
 |
144
hengo Mar 19, 2019 via Android
额，感觉你们工作量不饱和
|
 |
146
N1ceHua Mar 19, 2019
对不起，这个笑话挺好笑的。
|
 |
147
specita Mar 19, 2019
这有啥好争的...
|
 |
148
yunye Mar 19, 2019
你们俩都不行 我来当主管吧
|
 |
149
winglight2016 Mar 19, 2019
两个名字能争吵一天以至于想离职——工作量不饱和吧。。。顺便说一下，我的命名：
flag errorCode message |
 |
150
MrUser Mar 19, 2019
status 不能当“状态码”，这个词的意思是“状态”，值应该是“ error、ok、success ”
如果要为“状态码”取一个名字，也是“ code" 或 "status code" ------ 谁付钱听谁的，如果平级就向上级反馈，直到向上到付钱的那位为止，这也是为工作负责。 |
 |
151
agee Mar 19, 2019 via iPhone
能理解的情况下越短越好啊节省流量
|
 |
152
After00 Mar 19, 2019
这种东西能吵一天（刷新了我对事物的认知），也是厉害，说实话感觉好傻啊，争来争去有个屁用，改了能怎样，不改
又能怎样，又不影响什么。都不知道 lz 怎么想的。 |
 |
153
13913001584 Mar 19, 2019
你俩都够闲的，为这个吵一天。
errorCode 有哪些，errorMsg 有哪些定好了没有呢？ |
 |
154
ByteRan Mar 19, 2019
{
"code": 错误码(0 表示成功), "message": 错误消息, "data": 数据对象 } |
 |
156
SummerWQM Mar 19, 2019
{"code","msg":"","data":"int string array and so on"} 拿走不谢
|
 |
157
allenhu Mar 19, 2019
难道不应该是下面这样吗？
```javascript { "status" : "错误码"， "message" : "错误消息"， ...... } ``` |
 |
158
linbiaye Mar 19, 2019
errorCode 直译过来就是错误码，成功的时候也放这个字段么？
|
 |
159
RubyJack Mar 19, 2019
不知道说啥，给楼主拜个早年吧
|
 |
160
yongboy Mar 19, 2019
楼主经验不足吧，没有主管看得远。
作为代码开发者，需要遵循（领导）制定的规范，没什么可说的，除非你能够说服人家。 你和他争吵，就说明你自己已经错了。 |
 |
161
lancelock Mar 19, 2019
你们不要再吵了啦
|
 |
162
pynix Mar 19, 2019
不用错误吗，，，，有错误就直接 400 或者 5000
|
|
163
pynix Mar 19, 2019
500
|
 |
164
StephenHe Mar 19, 2019
感觉你们工作量不饱和
|
 |
165
jydeng Mar 19, 2019
```
{ status:“”， } ``` |
 |
166
dagger2 Mar 19, 2019
主管说话都不好使的吗，还可以不听然后按自己的来？
|
 |
167
wobushizhangsan Mar 19, 2019 via Android
提意见。达成一致，听领导的。达不成一致，领导对，听领导的，领导错，听领导的。总结：听领导的。
|
 |
168
gpg Mar 19, 2019
我给你一个建议
{ "status" : "code error"， "error" : "error"， ...... } |
 |
169
happinessnch Mar 19, 2019 1
我敢 75%的肯定你们的工程没有需求，需要严谨到一个接口命名要 100%符合设计理念。
主管有义务保证项目整体设计统一，出现分歧无明显最优解，或者无重大影响的时候，根据权责我个人建议依照主管意见执行。主管是否需要管这么细，不做评价。 如果因为这点小事就要离职的话，那下一家你肯定也呆不久，你这仅仅是单纯的赌气。我猜测主要原因是你们俩这次的沟通出了问题，或者语气、或者有误的理解。 设计不统一到处都是，各有各的设计思路，很多时候没有对错，越大的项目越需要个体的牺牲。 |
 |
170
ashCloud Mar 19, 2019
约定而已，至于吗。。。
|
 |
172
ResidualWind Mar 19, 2019
{
"code" : "编码"， "msg" : "编码说明"， ...... } |
 |
173
bayker Mar 19, 2019
{
"httpStatusCode": 200, "description": "" } |
 |
174
northernlights Mar 19, 2019
如果是我自己的项目：
{ "suc" : false, "msg" : "这是错误信息哦" } 如果是公司的项目，你管那么多干嘛呢。领导对你来说是甲方，甲方说啥就是啥。 |
 |
175
luw2007 Mar 19, 2019
如果是全新项目， 没有历史包袱，怎么命名觉得无伤大雅。
接口是包含在项目中。整个项目需要有统一的返回结构。 我觉得是主管的问题。这种很容易就能沟通好。主管没有能摆事实讲道理让你信服。反而让你产生离职的想法。那么就不是一个合格的管理者。 对于你的提议，我个人觉得。errCode 不如 code，errmMsg 不如 msg。简单就是美。 |
 |
176
flashrick Mar 19, 2019
我现在接口都是
code: msg: 200 正确 100 错误，特殊点的就是 101 102 这种 |
 |
177
Mitt Mar 19, 2019
事你来做，责任主管当。 所以从一开始这事你就没有谈论资本
|
 |
178
ooops Mar 19, 2019
先说，谁都不同意。业务上不建议用 HTTP status 作为成功和失败。2xx 好多可以认为是成功，100 也可以是成功，304 也是成功。用 status 就会联想到 HTTP status，不如叫 code，HTTP status 应该在网络基础库封装好，HTTP 错误都不该来到业务这一层。
|
 |
179
xFrye Mar 19, 2019
如果这个是每个接口的通用返回格式，我支持你主管的。
|
 |
180
runnerlee Mar 19, 2019
|
 |
181
hooych Mar 19, 2019
我是主管，我选第一种
|
 |
182
hoythan Mar 19, 2019
参考阿里巴巴的吧，code: 10000
|
 |
183
chengran630 Mar 19, 2019
我来说一个新的讨论点 - -
code 1 是 true 0 是 false 有人反对么 |
 |
184
orangeChar Mar 19, 2019
一点都不语义化 直接
{ "code":"状态码" "msg":"描述" } |
 |
185
zealinux Mar 19, 2019
讨厌 json 的 key 是 errorCode 这种，倾向于 key 用小些下划线。
````json { error_code: "错误码"， error_message : "错误消息"， } ``` |
 |
186
shidianxia Mar 19, 2019
|
 |
187
klgd Mar 19, 2019
吵什么吵，听我的
{ "code" : "编码"， "message" : "编码说明"， "content":{} } |
 |
188
baixiangcpp Mar 19, 2019
别离职了，你们挺合适的其实。
|
 |
189
findstrx Mar 19, 2019
按照 HTTP 的惯例“ https://tools.ietf.org/html/rfc2616#page-39 ”，status 命外应该算是惯例~
|
 |
190
licraft Mar 19, 2019
我和测试吵过，后来想想真没必要，工作中能心平气和的沟通很重要
|
 |
191
also24 Mar 19, 2019 2
我做组员的时候，我会详细说明这么做的理由，以及主管的方案的问题，然后由主管告诉我最终结果：
“那就改掉吧” 或者 “别 BB，按我说的做” 我做主管的时候，了解一下组员想这样做的原因，陈述一下自己的想法，然后给出最终方案： “那就改掉吧” 或者 “别 BB，按我说的做” 总而言之： 组员只要确保自己讲清楚理由，主管只需要确保收集足够的信息。 至于决策？你以为 “主管” 两个字是什么意思？ |
 |
192
whypool Mar 19, 2019
支持主管，一点屁事都做不好，不想写可以 gun，瞎比比啥
一个返回格式都能吵一天，那设计表岂不是要干一架？ |
 |
193
likuku Mar 19, 2019
人生苦短，浪费时间就是谋财害命
|
 |
194
xiangliangyu Mar 19, 2019
无关个人发展，无关大局，芝麻点小事的，主管说啥就是啥，没必要浪费大家时间！！！
|
 |
195
clovelu Mar 19, 2019
可以提出你的意见，如果主管已经拍板定下来，没啥大问题，那就听主管的. 擦，感觉主管不好当，定个格式都能被属下吵一天.
|
 |
196
Dogergo Mar 19, 2019
闲的蛋疼，找点事做不好么？这个吵的没有意义
|
 |
197
jinue9900 Mar 19, 2019
{
"code":0 "data":{} "error":{} } 我们公司是这样的其实规范定好对后面有帮助 |
 |
198
qiutianaimeili Mar 19, 2019
个人主管没错吧，因为 status 表示中立，只是一个状态，可以是成功到状态码，也可以是错误的状态码；如果按照楼主的那种，errorCode 只能表示错误的状态码了，那么成功的状态码岂不是要搞一个 successCode?
|
 |
199
c4f36e5766583218 Mar 19, 2019
角度刁钻。。。这有什么好纠结的？？？楼主刚毕业上班吗？
|
Select Language