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

@yiyi11 #107 你这个不全，完整版应该是这样：

喜欢就买，不行就分，多喝开水，重启试试。

还是工作不饱和

{ "errors":"错误消息";}
就这样，完了
code 按 restful 来

{"code":"200","msg":"........",......}这样可能比较好
一般没必要强调错误参数，返回的什么可能性都有，唯独错误率应该是低的，这是上线的接口的基本功。
所以在很少有错误发生的情况下，为其专门准备一个返回值位置，可能就有些多余，而且也不能从中反推出其他的可能状态，因为总会有其它的状态出现。
还有啊，每个人的想法都是不同的，在公司里面的话，就不能意气用事了，主管怎么说你就怎么做呗。做出来的东西又不是你自己的。不必纠结那么多，大家都是混口饭吃，都留一些情面嘛，好说话一些。

code, msg 就完了，越少越好
这个真的不值得吵

@fox0001 通用的 404 之类的还好说，有的时候根本不够用或者找不到合适的，还是要加个 status 之类的字段来判断到底什么错

@keepeye 看了一圈 这个方案我最喜欢 其他方案 看着脑阔疼

@reid2017 一毛一样+1，

这个话题唯一有点价值的就是 V 友们互（各）相（自）学（站）习（队）了

吵架算什么，有本事去尬舞啊

这也能吵？

为这点事情离职 不值得

我听说过有公司吵架的罚 2 个人牵手一下午的，好像在 b 站上看到的来着[滑稽]

我更想听听楼主以及主管这样设计的各自的理由是什么？？？

？？？ 315 楼了，所以为啥吵架？

在执行成功的时候，楼主的方式缺陷很大，具体事情具体分析，如果不去分析的话，主管的方案更具有普遍性

@HackerPainter
主管的方案里 status 只有两种状态，成功和失败，失败了就提示 errmsg 的内容，并不区分具体错误码。
错误码要来干什么，第一要准确定义错误，防止 msg 歧义，第二归类，错误码很多，第三，程序自动识别。
你都没说问题的背景是什么，不知道怎么评价。

这个帖子囊括了一天的笑点.哈哈哈

比较喜欢 GraphQL 的返回格式:

``` json
{
"data": { ... },
"errors": [ ... ],
"extensions": { ... }
}
```

@gtanyin https://linux.die.net/man/1/mesg
类色的还有 creat