和主管为一个接口输出真吵了一天，搞得都想离职，求怎么破

[HackerPainter]

主管想用的接口输出

{
  "status" : "错误码"，
  "error" : "错误消息"，
  ......
}

楼主想用的接口输出

{
  "errorCode": "错误码"，
  "errorMsg" : "错误消息"，
  ......
}

我在想一个接口至于争吵一天吗？最后我妥协了，现在感觉好想离职，请问怎么破

首先非常感谢各位社友的回复和讨论，在看各位社友的评论中学到了很多东西，果然三人行必有我师焉！

• 社区有些社友可能认为这种接口争吵没啥意义，随便定义一个就行，但如果这个接口被几千人使用甚至被几万人使用，那就得对这个接口好好设计了。如果连自己都对自己提供的接口不保持敬畏，那就别指望用户对你提供的接口保持敬畏，对于用户的抱怨牢骚那只能全部接下。过去几年里很多用户对我们提供的接口出现过各种各样的抱怨（每个用户都有一套自己心目中的接口，就像社区内留言出现很多接口定义），如果接口提供方的接口与接口使用方心目中的接口不一样就会出现或多或少有抱怨和吐槽。为了尽量让用户用的爽，减少用户的抱怨，所以就和主管对接口进行了争吵（善意的争吵），至于想离职是其它方面的原因；

• 有些社友可能认为和主管争吵不太好，主管想做成什么样自己就做成什么样。但你真认为这种状态好吗？即使你照做了，你觉得主管认可你吗？在互联网环境下，得多与主管、同事讨论讨论问题，有些难解的问题就是在讨论中产出解决方案的。过去几年和主管同事争吵过无数次甚至拍桌子，差点打起来，但这种都是idea的碰撞，只有碰撞中才能产出好的idea，其实碰撞完后同事主管都会私下交流这个都是各自想法，不代表其他含义，不要往心里去。对于主管要你做啥你就做啥，那主管招你有何用，主管可以招任何一个人来替换你，这样你的自身竞争力在哪里。一个程序员要往高处发展，要学会自己去发现问题去解决问题，而不是等待主管安排问题，比如主管交给你一个手工线上部署任务（需要经常部署），结果你每次都可以手工无故障的部署完成，但这种结果是主管希望的吗，主管再找一个人也可以无故障的手工部署，但如果你把手工线上部署做成自动化工具一键部署，可以节约时间且无风险，这样在主管看来你就是不可替代，能自己对问题提出解决方案；

• 程序之美应该包含编程之美、接口之美和测试之美。如果有一段程序编程无规范、接口随便定义，无单测和功能测试，让你去接手这段代码，你会怎么想？所以还是对接口保持敬畏之心，多花点时间定义接口，少花点时间答疑和听用户的抱怨；

下面各出了很多社友的接口定义，可以供借鉴，排名不分先后，可以投票😄

{
    "code": "错误码",
    "message": "错误消息"
}

{
    "errno" : "错误码"，
    "message" : "错误消息"
}

{
    "status": "错误码",
    "error": "错误消息"
}

{
    "status": "错误码",
    "msg": "错误消息"
}

{
    "errKey": "错误码",
    "errMsg": "错误消息"
}

{
    "status": "错误码",
    "error": "错误消息",
    "errorCode": "错误码",
    "errorMsg": "错误消息"
}

{
    "statusCode": "错误码",
    "statusMsg": "错误消息"
}

{
    "error_code": "错误码",
    "error_msg": "错误消息"
}

[GeruzoniAnsasu]

我感觉诸位也能在这个帖子里吵一天。。。

[Heavytiger]

怎么不用下划线:error_code

[vimiix]

我觉得主管的更通用一些，code 可以兼容其他情况，并不一定都是 error 情况。

[yiyi11]

下属唔可以啵上司嘴。

[wingspread]

钻牛角尖

[wingspread]

建议辞职。

[yiyi11]

多喝热水，喜欢就买，不行就分，遵循自己的内心。

[zwh2698]

其实更建议将 error， 修改为 message.还有 json 不要用驼峰命名，全小写。因为有些语言对大写解析会出错。小写都没有问题

[ben1024]

"一个接口至于争吵一天吗?"，直接安装你主管的来
不开心就内部用自己的，外部封装一层输出层

[hahaayaoyaoyao]

@keepeye 这种是最好的

[karllynn]

支持主管

这种只是风格问题的设计，你居然不听领导的，我觉得你在哪都干不下去。

[zzzzzzZ]

果然大部分用的都是这种：
{
"code"：0，
"msg"：null，
"data"：{}，
}

[longxboy]

这就是一个风格，没有谁对谁错，定下一个标准就行

[jrient]

{
"status":0,
"msg":''
}

[StarRED]

主管是背锅的，要听他的。

[az422]

闲的蛋疼，从楼主示例来说，两种方案功能是一样的，就是命名不同而已，这也能吵我服了

[Lonely]

@struggle001 你是认真的还是搞笑的

[udumbara]

庆幸自己没有和这样的人（楼主和主管）共事

[akatquas]

@raysonx There are only three hard things in Computer Science: cache invalidation and naming things.

[fanhaipeng0403]

吵这个有意思吗

[netstu]

这种问题明明是楼主的问题，较真，不服气

我要是有这样的下属真想干掉，带着累

我的理由是：这根本不是什么大问题，如果真是主管有问题，那可以较真，但这明显不是

[reid2017]

@keepeye 跟我设计的一毛一样

[auh]

有分歧很正常，不过我看第一种没毛病。

[st2udio]

{
"code": 0,
"data": null,
"msg": null
}

难道这么多年我写错了?
非要选，我支持主管那种。

还有，这种东西，争吵一天？

[wfd0807]

你应该离职，我支持你

[focusheart]

{ 'error': true, 'err01': true, 'err99': false, ...} 还有这种错误码呢……万一遇到了岂不是要吵 99 天……
没多大事儿，看开些~

[donyee]

我推荐是
{
"result_ode": "返回码"，
"result_msg" : "返回消息"，
......
}

[abcbuzhiming]

首先主管是背锅的，你不能因为要坚持你的理念，就把责任扔给别人，坚持理念者要付出应该的代价。其次，你有离职的自由，强烈建议你换个地方，自己当主管

[fxxkgw]

首先如果是 python 你这样肯定不行吧。。

[dxgfalcongbit]

每个人的想法不一样很正常，所以需要有个拍板的。

[nihonngo]

这有啥吵架的，不用上班啊

[lhstock]

（此处只说命名，不提结构）支持主管。首先。其实用什么都无伤大雅。如果说易懂按照不同规范来看，”易懂“本身就是不确定的，所以随便用。那么为什么要统一。比如 ABC 三人三种习惯，这很常见，当然谁都没用错（不引战），没有规范，格式必然五花八门。那么 debug 的时候就会很痛苦了，因此有了需求：把习惯”统一“。最终只是有了一道选择题而已。可能 1：相对而言你不具有选择权。2：这个选项早已选好。最后：规范这种东西有人有能力定制一定程度上说明了公司的底蕴。毕竟大部分公司没用这种东西。羡慕

[dany813]

笑哭

[TheWalkingDead]

code
data
message

[niuoh]

@keepeye 我也用这个格式 同道中人啊

[ericgui]

领导估计都想让你离职了

你搞笑呢吧，这个破事都能吵架，到底谁是老大？

[simple2025]

直接按照 http 的 status 和 message

[NotFamous]

这都算好了，跟我搭档的后台，，，英文单词经常拼错，然后光是“ ID ”这个字段就有好几种字段名：ID、Id、id，一点规范都没有

[webjin1]

{
"cuowudaima": "错误代码"，
"cuowuxiaoxi" : "错误消息"，
......
}
我觉得这样好

[arsenal4]

主管唯一的错误就是为什么不在吵到半天的时候还不把你开掉

[hayvane]

说实话，都不好！非要二选一那肯定是选主管的，原因楼上有人分析了。这都能吵一天，我是主管早让你滚蛋了！

[index90]

楼主是一个刚进 BAT 的毕业生，太嫩了。

回到楼主的问题，该不该离职。

如果你认识到自己的问题，建议你请主管喝杯咖啡，虚心学习。

如果你依然觉得自己是对的，BAT 不是你的平台，那就离职出外面去看看。

[flyingghost]

请把字段的可选、必选确定一下。
方案 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!

[hengo]

额，感觉你们工作量不饱和

[Vegetable]

@geelaw 错误码表示成功状态?你听着不别扭吗?那就叫接口状态码吧?

[N1ceHua]

对不起，这个笑话挺好笑的。

[specita]

这有啥好争的...

[yunye]

你们俩都不行 我来当主管吧

[winglight2016]

两个名字能争吵一天以至于想离职——工作量不饱和吧。。。顺便说一下，我的命名：
flag
errorCode
message

[MrUser]

status 不能当“状态码”，这个词的意思是“状态”，值应该是“ error、ok、success ”
如果要为“状态码”取一个名字，也是“ code" 或 "status code"
------
谁付钱听谁的，如果平级就向上级反馈，直到向上到付钱的那位为止，这也是为工作负责。

[agee]

能理解的情况下越短越好啊节省流量

[After00]

这种东西能吵一天（刷新了我对事物的认知），也是厉害，说实话感觉好傻啊，争来争去有个屁用，改了能怎样，不改

又能怎样，又不影响什么。都不知道 lz 怎么想的。

[13913001584]

你俩都够闲的，为这个吵一天。
errorCode 有哪些，errorMsg 有哪些定好了没有呢？

[ByteRan]

{
"code": 错误码(0 表示成功),
"message": 错误消息,
"data": 数据对象
}

[Cat73]

@keepeye 跟我们的一毛一样

[SummerWQM]

{"code","msg":"","data":"int string array and so on"} 拿走不谢

[allenhu]

难道不应该是下面这样吗？
```javascript
{
"status" : "错误码"，
"message" : "错误消息"，
......
}
```

[linbiaye]

errorCode 直译过来就是错误码，成功的时候也放这个字段么？

[RubyJack]

不知道说啥，给楼主拜个早年吧

[yongboy]

楼主经验不足吧，没有主管看得远。
作为代码开发者，需要遵循（领导）制定的规范，没什么可说的，除非你能够说服人家。
你和他争吵，就说明你自己已经错了。

[lancelock]

你们不要再吵了啦

[pynix]

不用错误吗，，，，有错误就直接 400 或者 5000

[pynix]

500

[StephenHe]

感觉你们工作量不饱和

[jydeng]

```
{
status:“”，

}
```

[dagger2]

主管说话都不好使的吗，还可以不听然后按自己的来？

[wobushizhangsan]

提意见。达成一致，听领导的。达不成一致，领导对，听领导的，领导错，听领导的。总结：听领导的。

[gpg]

我给你一个建议
{
"status" : "code error"，
"error" : "error"，
......
}

[happinessnch]

我敢 75%的肯定你们的工程没有需求，需要严谨到一个接口命名要 100%符合设计理念。
主管有义务保证项目整体设计统一，出现分歧无明显最优解，或者无重大影响的时候，根据权责我个人建议依照主管意见执行。主管是否需要管这么细，不做评价。

如果因为这点小事就要离职的话，那下一家你肯定也呆不久，你这仅仅是单纯的赌气。我猜测主要原因是你们俩这次的沟通出了问题，或者语气、或者有误的理解。

设计不统一到处都是，各有各的设计思路，很多时候没有对错，越大的项目越需要个体的牺牲。

[ashCloud]

约定而已，至于吗。。。

[ooops]

@keepeye 不能同意更多

[ResidualWind]

{
"code" : "编码"，
"msg" : "编码说明"，
......
}

[bayker]

{
"httpStatusCode": 200,
"description": ""
}

[northernlights]

如果是我自己的项目：
{
"suc" : false,
"msg" : "这是错误信息哦"
}
如果是公司的项目，你管那么多干嘛呢。领导对你来说是甲方，甲方说啥就是啥。

[luw2007]

如果是全新项目， 没有历史包袱，怎么命名觉得无伤大雅。
接口是包含在项目中。整个项目需要有统一的返回结构。

我觉得是主管的问题。这种很容易就能沟通好。主管没有能摆事实讲道理让你信服。反而让你产生离职的想法。那么就不是一个合格的管理者。

对于你的提议，我个人觉得。errCode 不如 code，errmMsg 不如 msg。简单就是美。

[flashrick]

我现在接口都是
code:
msg:
200 正确 100 错误，特殊点的就是 101 102 这种

[Mitt]

事你来做，责任主管当。 所以从一开始这事你就没有谈论资本

[ooops]

先说，谁都不同意。业务上不建议用 HTTP status 作为成功和失败。2xx 好多可以认为是成功，100 也可以是成功，304 也是成功。用 status 就会联想到 HTTP status，不如叫 code，HTTP status 应该在网络基础库封装好，HTTP 错误都不该来到业务这一层。

[xFrye]

如果这个是每个接口的通用返回格式，我支持你主管的。

[runnerlee]

我都是找大厂的例子出来怼我老大的:

https://open.weibo.com/wiki/Error_code
https://open.taobao.com/doc.htm?docId=114&docType=1
https://en.wikipedia.org/wiki/HATEOAS

[hooych]

我是主管，我选第一种

[hoythan]

参考阿里巴巴的吧，code: 10000

[chengran630]

我来说一个新的讨论点 - -
code
1 是 true
0 是 false
有人反对么

[orangeChar]

一点都不语义化 直接
{
"code":"状态码"
"msg":"描述"
}

[zealinux]

讨厌 json 的 key 是 errorCode 这种，倾向于 key 用小些下划线。

````json
{
error_code: "错误码"，
error_message : "错误消息"，
}

```

[shidianxia]

https://cloud.google.com/apis/design/errors

[klgd]

吵什么吵，听我的
{
"code" : "编码"，
"message" : "编码说明"，
"content":{}
}

[baixiangcpp]

别离职了，你们挺合适的其实。

[findstrx]

按照 HTTP 的惯例“ https://tools.ietf.org/html/rfc2616#page-39 ”，status 命外应该算是惯例~

[licraft]

我和测试吵过，后来想想真没必要，工作中能心平气和的沟通很重要

[also24]

我做组员的时候，我会详细说明这么做的理由，以及主管的方案的问题，然后由主管告诉我最终结果：
“那就改掉吧” 或者 “别 BB，按我说的做”

我做主管的时候，了解一下组员想这样做的原因，陈述一下自己的想法，然后给出最终方案：
“那就改掉吧” 或者 “别 BB，按我说的做”


总而言之：
组员只要确保自己讲清楚理由，主管只需要确保收集足够的信息。
至于决策？你以为 “主管” 两个字是什么意思？

[whypool]

支持主管，一点屁事都做不好，不想写可以 gun，瞎比比啥
一个返回格式都能吵一天，那设计表岂不是要干一架？

[likuku]

人生苦短，浪费时间就是谋财害命

[xiangliangyu]

无关个人发展，无关大局，芝麻点小事的，主管说啥就是啥，没必要浪费大家时间！！！

[clovelu]

可以提出你的意见，如果主管已经拍板定下来，没啥大问题，那就听主管的. 擦，感觉主管不好当，定个格式都能被属下吵一天.

[Dogergo]

闲的蛋疼，找点事做不好么？这个吵的没有意义

[jinue9900]

{
"code":0
"data":{}
"error":{}
}
我们公司是这样的其实规范定好对后面有帮助

[qiutianaimeili]

个人主管没错吧，因为 status 表示中立，只是一个状态，可以是成功到状态码，也可以是错误的状态码；如果按照楼主的那种，errorCode 只能表示错误的状态码了，那么成功的状态码岂不是要搞一个 successCode?

[c4f36e5766583218]

角度刁钻。。。这有什么好纠结的？？？楼主刚毕业上班吗？

[jon]

@yiyi11 很有画面感蛤蛤蛤