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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2077 天前的主题，其中的信息可能已经有所发展或是发生改变。

主管想用的接口输出

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

楼主想用的接口输出

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

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

第 1 条附言 · 2019-03-20 21:47:08 +08:00

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

社区有些社友可能认为这种接口争吵没啥意义，随便定义一个就行，但如果这个接口被几千人使用甚至被几万人使用，那就得对这个接口好好设计了。如果连自己都对自己提供的接口不保持敬畏，那就别指望用户对你提供的接口保持敬畏，对于用户的抱怨牢骚那只能全部接下。过去几年里很多用户对我们提供的接口出现过各种各样的抱怨（每个用户都有一套自己心目中的接口，就像社区内留言出现很多接口定义），如果接口提供方的接口与接口使用方心目中的接口不一样就会出现或多或少有抱怨和吐槽。为了尽量让用户用的爽，减少用户的抱怨，所以就和主管对接口进行了争吵（善意的争吵），至于想离职是其它方面的原因；
有些社友可能认为和主管争吵不太好，主管想做成什么样自己就做成什么样。但你真认为这种状态好吗？即使你照做了，你觉得主管认可你吗？在互联网环境下，得多与主管、同事讨论讨论问题，有些难解的问题就是在讨论中产出解决方案的。过去几年和主管同事争吵过无数次甚至拍桌子，差点打起来，但这种都是idea的碰撞，只有碰撞中才能产出好的idea，其实碰撞完后同事主管都会私下交流这个都是各自想法，不代表其他含义，不要往心里去。对于主管要你做啥你就做啥，那主管招你有何用，主管可以招任何一个人来替换你，这样你的自身竞争力在哪里。一个程序员要往高处发展，要学会自己去发现问题去解决问题，而不是等待主管安排问题，比如主管交给你一个手工线上部署任务（需要经常部署），结果你每次都可以手工无故障的部署完成，但这种结果是主管希望的吗，主管再找一个人也可以无故障的手工部署，但如果你把手工线上部署做成自动化工具一键部署，可以节约时间且无风险，这样在主管看来你就是不可替代，能自己对问题提出解决方案；
程序之美应该包含编程之美、接口之美和测试之美。如果有一段程序编程无规范、接口随便定义，无单测和功能测试，让你去接手这段代码，你会怎么想？所以还是对接口保持敬畏之心，多花点时间定义接口，少花点时间答疑和听用户的抱怨；

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

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

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

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

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

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

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

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

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

错误

接口

输出

离职

436 条回复 • 2020-12-01 11:05:06 +08:00

1 2 3 4 5

❮

❯

201

jon

2019-03-19 14:32:23 +08:00

主管那个设计更好把,你这个有点冗余,要是没有错误码呢,而且状态不能算错误的也不能算正确的情况怎么办

202

lastpass

2019-03-19 14:36:43 +08:00

作为一名前端后端都要自己写的全干。
表示我想用啥就用啥。
{
error:"error"//错误时存在
success:"success"//正确时存在
msg:......
data:......
}
不接受任何反驳。
因为只有我一个人干。
没有人反驳我。

203

spoony

2019-03-19 14:37:49 +08:00 via iPhone

都怪袁隆平系列

204

king2014

2019-03-19 14:38:40 +08:00

要么是主管太软在你们公司没地位，要么就是楼主情商低自以为是，就这种事情能争论一天，最后还来 V2EX 发个贴求安慰？

205

amon

2019-03-19 14:38:51 +08:00

@gtanyin 看了全贴，最惨的还是你。
mesg，搜狗提示：么事干。

206

bzj

2019-03-19 14:39:48 +08:00

情商低没前途

207

2019-03-19 14:39:49 +08:00

code msg data 了解一下！

208

loading

2019-03-19 14:40:34 +08:00 via Android

额，我支持主管。

209

loading

2019-03-19 14:41:02 +08:00 via Android

@fy 我目前就是与你这个类似。

210

xiaowoniu

2019-03-19 14:42:21 +08:00

主管的建议好点

211

notreami

2019-03-19 14:42:47 +08:00

这有啥好争论的，两种方式都很差。
基于一般接口请求 90%以上应该是正确请求返回，
那么正确请求返回的数据，error 填啥？ errorCode 填啥？ errorMsg 填啥？填了又有啥用？

基于接口返回正确数据，调用方一般不会关注 error 信息，
那么这种每次请求都要带着好几个无用字符的接口，浪费用户流量，浪费公司流量，拖慢互联网，你们心里过意的去嘛？

212

karnaugh

2019-03-19 14:43:09 +08:00

感觉莫名其妙，多关注一些真正有意义的玩意不行么，这玩意都放在这个位置了还能有什么歧义么

真要说的话，你们主管那个比你的少 8 个字符，少用了点流量，这倒是挺有意义的

213

ghos

2019-03-19 14:43:14 +08:00

来看看我们公司的
{code: 200, msg: "操作成功", serverTime: "1552960256560", data: {…}, success: true}

214

suisuipingan

2019-03-19 14:43:18 +08:00

看成想离婚，吓我一跳

215

Tink

2019-03-19 14:48:15 +08:00

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

216

busfool

2019-03-19 14:50:38 +08:00 via Android

虽然较真精神值得鼓励，但是我还是想说一句，听领导的，领导说怎么做就怎么做，当然指的是工作上。只要不违法，不损害你身心健康，听领导的。

217

meepo3927

2019-03-19 14:50:58 +08:00

别吵了，用这个吧：

{
“ code": 11,
"msg": "fuck it."
}

218

cmonkey

2019-03-19 14:51:52 +08:00

坚决辞职，连换回码都不听你的，这届主管不行

219

rming

2019-03-19 14:58:21 +08:00

主管定的是『规则』，你的是改进『建议』。
主管可以接受或者不接受，因为『规则』可能是适用于多个组员、多个项目组的，而你的建议可能仅适用于你自己，或者部分成员，主管有责任像你解释为什么这样设计，也有权利不接受你的建议。
从代码的角度说好与不好，很简单区分，但是从做事的角度分析，可能主管考虑的影响因素会比你更多，因此，你有权利提出建议，但是当主管不接受建议时，不要太较真，因为你认为不恰当的方案，从其他人的角度去看，也有可能是最优解。

220

rming

2019-03-19 15:00:22 +08:00

btw. 都叫主管了，人家说了还不算么？

221

xfriday

2019-03-19 15:00:28 +08:00

你们公司真闲，有这功夫还不去解决实际问题

222

zcljy

2019-03-19 15:00:56 +08:00

听我的直接{code:200,msg:真香}

223

darkjoker

2019-03-19 15:01:07 +08:00

建议楼主离职吧，其他问题还是会吵的。

224

night98

2019-03-19 15:03:22 +08:00

{
code:200
msg:""
data:xxx
}

and
{
code:400
msg:"用户名或密码错误"
data:
}

225

hideonwhere

2019-03-19 15:07:25 +08:00

@HackerPainter 0 代表成功其他代表错误错误分别对应各自代码

226

LemonCoo1

2019-03-19 15:08:44 +08:00

亲亲，这边建议您赶紧离职呢

227

madao

2019-03-19 15:09:58 +08:00

@HackerPainter 典型的「自行车棚顶」问题，你可以了解下这个著名的邮件： https://shed.bike/。

另外主管的方案更优，作为前端你如果真不喜欢，你可以把接口自己实现一个中转接口的服务变成你希望的样子。

228

j717273419

2019-03-19 15:11:56 +08:00

主管想用的接口输出

{
"status" : "错误码"，
"error" : "错误消息"，
......
}
楼主想用的接口输出

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

==============正确答案来了==============
{
"错误码": "12345"，
"错误消息" : "争论超时"，
......
}

229

hahasong

2019-03-19 15:11:57 +08:00

code msg data 标准答案。我不是针对楼主，我是说你们两个的答案都是辣鸡

230

fenglangjuxu

2019-03-19 15:13:16 +08:00

支持主管,这很简单的事情,争吵一天,真怀疑你们的办事能力和效率

231

tao1991123

2019-03-19 15:15:10 +08:00

闲得蛋疼

232

holy_sin

2019-03-19 15:16:31 +08:00

status, msg

233

seaguest

2019-03-19 15:16:35 +08:00

我觉的要么

```
{
"code": 0,
"message": "success"
}
```
或者

```
{
"err_code": 0,
"err_msg": "success"
}

```
都可以，用 status 字段容易和 http 的状态码混淆，这里返回的 code 应该是业务逻辑的代码。

以前使用第二种，现在公司的规范是第一个，觉得都可以。

234

frozenway

2019-03-19 15:20:54 +08:00

{

"jie_kou_cuo_wu_dai_ma" : 123,
"jie_kou_cuo_wu_xin_xi": sdhdhdh

}

235

2805408253

2019-03-19 15:26:13 +08:00

{
"code":
"msg"
"result"
}

236

myalexu

2019-03-19 15:29:01 +08:00

:)不是技术问题，是权力问题

237

summic

2019-03-19 15:30:39 +08:00

楼主发了三个帖子

有两个提到想离职

两次时间间隔一年

不知道是一直没有痛下决心，

还是在新公司又想离职了

238

0Zed

2019-03-19 15:35:00 +08:00

“吔屎啦,梁非凡” 画面感。最后怕不是也要 “对不起，非凡哥”

239

oIMOo

2019-03-19 15:36:26 +08:00

exit(1)

240

stevenhawking

2019-03-19 15:37:01 +08:00

Yaun Loungping: The bigest mistake i made is that feed you guys too full.

241

chengyulong

2019-03-19 15:39:12 +08:00

就这单 P 事也要争论么

242

geelaw

2019-03-19 15:40:22 +08:00 via iPhone

@Vegetable #145 所以你还是停留在字面理解咯🙄

从历史惯用法的角度来说：传统的 POSIX 用 errno 存放错误代码，0 表示没有错误； Win32 的错误代码中 ERROR_SUCCESS 表示没有错误。

遇到和想像含义不符的词汇时第一步是查询它（在这个上下文）的定义，这是任何受过形式化逻辑训练的人需要遵守的第一个规则，例如数学上的“极限”与它作为“限度”的含义完全不同。

另外，我并不反对用 status code 表达同一个意思，不过并没有哪个更好的说法。同样的方式，还可以 argue status code 包含“状态”的含义，但不是所有情况都应该用“状态”来表达。但无论如何，先去寻找定义（也就是查看文档）才是正确的。

243

Eiden

2019-03-19 15:47:08 +08:00 via Android

楼主说得对，我建议楼主锤爆主管狗头然后离职

244

hoyixi

2019-03-19 15:47:10 +08:00

蛋疼，至于吗。

只要需求明确，文档定死了就行。

最恐怖得是：今天领导想这个格式，明天领导又想那个格式。你具体干活的，这才叫痛苦。

如果管事儿的头头，习惯拍板定好，求之不得。

245

fakeshadow

2019-03-19 15:51:28 +08:00

你也是说了至于吵一天么？所以至于为了这个离职么？

246

ck65

2019-03-19 15:54:08 +08:00

下面上场的是摸鱼比赛男子双摸的某 IT 公司代表队。

247

sun1991

2019-03-19 15:57:26 +08:00

@raysonx
There are only two hard things in Computer Science: cache invalidation and naming things, and off by 1 error.
-- Phil Karlton

抱歉, 忍不住╮(￣▽￣")╭

248

sannyzeng

2019-03-19 15:58:03 +08:00

我喜欢用
{
errNo:0,
errMsg:"",
data:xxxxxx
}

249

yhxx

2019-03-19 16:05:03 +08:00

@keepeye 强行反驳，成功不能用 0，随便用 1、200 之类的都行，就是不能用 0，总有后端分不清 0 和"0"

250

catalina

2019-03-19 16:05:12 +08:00 via Android

这个能吵一天？！

251

Azmaveth

2019-03-19 16:06:26 +08:00

作为产品狗来发言
{
"code" : "状态码"，
"msg" : "状态消息"，
......
}

252

mysunshinedreams

2019-03-19 16:07:12 +08:00

正常相应不配拥有 code ？

253

JR1024

2019-03-19 16:10:23 +08:00

{
"rs_code" : "状态码"，
"rs_msg" : "消息"，
......
}

254

cai314494687

2019-03-19 16:10:50 +08:00

我们是

{
"code" : "错误码"，
"message" : "错误消息"，
......
}

255

iyangyuan

2019-03-19 16:18:47 +08:00

{
"status": 0, //非 0 表示业务异常。
"errmsg": "", //异常时的提示信息；正常时可省略。
"data": {} //业务数据；异常时可省略；正常时一定为对象，不可以直接返回列表(`"data": []`的形式无法扩展)。
}

256

xiaowangge

2019-03-19 16:34:05 +08:00

看我司的返回：

private Byte ret;
private Object data;
private String msg;

257

appmanagecluster

2019-03-19 16:38:09 +08:00

闲着多刷刷论坛不好吗

258

Vegetable

2019-03-19 16:42:09 +08:00

@geelaw 谈历史合适吗?还是因为没有规则所以会出现莫名奇妙的历史包袱.errcode:0 和 exit(1)这种设计,设计的时候可没考虑人能不能看懂.9102 年了,还要这样吗

259

wangxiaoaer

2019-03-19 16:42:23 +08:00 via Android

@keepeye 哈哈，跟我们在用的一模一样

260

CodeCore

2019-03-19 16:47:40 +08:00

code:
msg:
data:
多好....你们俩真是又菜又闲, 还自以为是.......你们这公司危险了....

261

mandy0119

2019-03-19 16:49:19 +08:00

我觉得技术而言两者差距不大，哪个方案好其他人已经说了很多了。
工作上，是你的问题，既然他是主管，在这种无伤大雅的小地方，顺从他的意见是一个职业素养的问题吧。如果以后你是主管，你要求用 errorCode，下属非要用 status，你会有啥感觉呢~~~花了一天的时候已经耽误了不少工作了吧，还是你们工作很清闲啊。。。
他的问题在于管理有问题，为啥这种小事下属会跟他吵一天。。。

262

S9Yh4wIFsBG7jnE4

2019-03-19 16:49:20 +08:00

袁隆平：还是让你们吃的太饱了.jpg

263

silvernoo

2019-03-19 16:50:54 +08:00

建议离职

264

zw1027

2019-03-19 16:51:27 +08:00

code msg data

学到咯...

265

Sapp

2019-03-19 16:51:56 +08:00

离职吧，别浪费公司钱了

266

xiwangzishi

2019-03-19 16:53:07 +08:00

亲，这边建议你立即离职哟。

267

Felldeadbird

2019-03-19 16:53:47 +08:00

楼主血气方刚啊，工作很多时候都会遇到这种不爽的，但是谁发钱给你的。你记住就行了。那，还争什么。工作就是服从啊。

268

MrStark

2019-03-19 16:56:12 +08:00

code 不一定是错误码的，有些特殊的状态码也可以放这个字段的嘛，所以你这个 errorCode 还真不行。
```
{
"code" : "",
"message" : "",
"data" : {}
}
```
简单直接

269

sheny

2019-03-19 16:57:25 +08:00

msg。。。多写几个字母不行嘛，不能想当然一看到就知道是 message 呀。不然我也缩写 localDescription localDp

270

sumu

2019-03-19 16:57:26 +08:00

这个主管也太失败了。如果换作是我，这种小事才不会关注，但如果关注到了，那你直接执行就是了，有异议可以提出来，但没有原则性问题，请按我得来，为这点小事争吵？秒开你。
这个开发也太失败了。此处与程序逻辑毫无关系，只是仁者见仁的事情，如果很关心，只能说明自己没能力看到 big piciture，那作为一个程序员，能力天花板之低，也是可以预期的。为一点破事与 leader 争吵，说明做人也够呛。double 失败啊

271

vtoee

2019-03-19 16:59:27 +08:00

@lastpass 厉害的全栈

272

Jaycee

2019-03-19 17:02:23 +08:00

主管没魄力，定好了执行就行。

273

cpdyj0

2019-03-19 17:02:35 +08:00

我也提一个：
{
"result": "ErrorCode|ErrMsg"
}
[手动狗头]

274

cnbobolee

2019-03-19 17:04:43 +08:00

这都可以吵架，你们公司比较闲。

275

Rect

2019-03-19 17:08:43 +08:00

@tabris17 errno 是啥...

276

CodeCore

2019-03-19 17:14:01 +08:00

@Rect error number 缩写, POSIX 接口错误码就是这个.
https://en.wikipedia.org/wiki/Errno.h

277

ykswang

2019-03-19 17:17:42 +08:00

key 索引带大小写的都是没有踩过坑

278

zhea55

2019-03-19 17:18:32 +08:00

刚看了 github

成功直接返回结果。

失败用 http code 响应。方便多了

各位公司都是微软 google 吗，需要像 windows 操作系统一样，搞那么多状态吗？

是有一个表，可以查每个 code 的含义吗？

什么东西都没有，就喜欢造轮子，业务冗余化，复杂化

显示自己多么牛 b。

279

tabris17

2019-03-19 17:19:44 +08:00

@Rect error number 的缩写。C 语言标准库里有个 errno.h

280

liuxu

2019-03-19 17:20:59 +08:00

我司：

{
"status" : "状态码"，
"message" : "英文解释"，
"chinese_message" : "中文解释"，
"data" : 额外数据，

}

281

edk24

2019-03-19 17:23:36 +08:00

我个人更倾向于
```
{
"code": 200,
"msg": "操作成功",
...
}
```
或者
```
{
"status": 200,
"msg": "操作成功",
...
}
```

简洁又直观, 让项目任何接口都必须**至少**带"code/status". 定死一个**状态码**而不是错误才出现的**错误码**.

至少抓包的很多接口是这么干的. 又便于和前端对接. 否则你这个**错误码**会让前端多出一个可以忽略的`if isset`操作

282

karllynn

2019-03-19 17:23:57 +08:00

@zhea55 你写过代码么。。业务错误你不给错误码，前端怎么根据错误提示用户？

283

lepig

2019-03-19 17:28:06 +08:00

要是我我就这样
```json
{
"code": "ooo",
"error": "xxx"
}
```

284

zhea55

2019-03-19 17:30:21 +08:00

@karllynn 哎，是不是非要我说

一些人对 http 协议，http 状态一无所知，

然后开始自己造轮子，自己搞状态

没有这种 sb 响应，就不能提示用户了吗？

再说了，做后端开发，应该把精力放在尽力解决所有 bug，以及服务的可用状态。

而不是提前设计好 error 状态，随时准备给用户甩锅

请问一句，用户看到你的错误，是什么心情？

285

lepig

2019-03-19 17:30:49 +08:00

我以前也喜欢搞这种所谓是 code，近几年不怎么用了。因为开始结合用 http status_code，如果错误直接报提示文案就好了。

搞那么多 errorcode 谁认识呢？还得去字典里找文案受罪

286

feikeq

2019-03-19 17:34:14 +08:00

我也选第一种，其实这没什么好争的.....
我的接口平常都这样设计，error 直接返回错误信息，不用那个什么代码，还要专门解释错误代码是什么意思...

{
"meta": {
"error": "This username already exists (这个用户名已经存在)",
"msg": "Request was successful (请求成功)"
},
"data": "数据"
}