喷了一个没写过接口的后台服务器开发人员的后果

[tyo]

刚去一个公司，喷了一个没写过接口的后台开发人员，结果搞的自己也很 Lower 。喷的原因很简单，接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名。 现在决心不说话，避免被说成是心态不好，大惊小怪。好无语。求安慰。

重要的不是能力，而是和谐的团队氛围，你认同这句话吗？

[killerv]

@noli 并不是非得严格按照 http 状态码返回， 200 的 http code 加上 json 没问题

[mazyi]

接口定义好了就不准备，变了就骂，

[pengfei]

有接口设计文档呀

[shenhongbang]

想解决问题呢就好好说话好好沟通，想单纯的干架就是一上来就喷喽

[noli]

@laoyur @des @FanError @csx163 几位没在大公司干过吧？

[noli]

@laoyur @des @FanError @csx163 抱歉，手快没回复完就发出去了
赶紧把锅丢出去才是正道。
反正 RESTFul 规范在那里，你要另外发明一个协议麻烦你仔细写出来。

[holy_sin]

你咋没削他呢

[yura93]

接口地址和参数和 Json 例子不是应该测试完毕 API 后放到内部开发平台上给前面人用吗?也不是需求变,自己频繁更改,可能没经验

[kanezeng]

@noli 大家说得没错啊， RESTFul 不是协议，也不是规范，只不过是诸多 WEB API 设计架构中被比较多人说得比较多的一种而已。
没人规定说 WEB API 一定要按 REST 来设计，事实上能看到的很多 API 要么并不按 REST 来做，要么并没有严格按照 REST 来做。

总结一下，上面说的那么些，我想表达的是 REST 只不过是一种架构，做 WEB API 时不需要一定要跟着他，同样大家在这里讨论 WEB API 的时候，也不需要拿他来说什么。

那么说回用 HTTP 状态码，还是单独返回一个状态码？这个我估计 V2 上可能都争论过很多次，支持的双方都有吧。
从我个人来说，我更喜欢单独返回一个状态码，用来把业务逻辑的状态，和非业务逻辑的状态区分开来。

再总结一下，后面说得这么些，我想表达的这两种做法没有绝对的对错，没有必要因为别人和自己的选择不同而喷对方。这个选择应该是公司来做，如果公司没做好，喷的是公司。

[noli]

@kanezeng 针对一个具体项目来说，选择 RESTful 规范就是一个省力的做法。

[mikulch]

感觉国内的人工作的怨气很大，性格很焦躁啊。
是不是觉得你喷了别人了所以显得自己特别牛逼？
当工作合作上出现问题的时候，自己是否想过，做过下面这些？

1. 对方这样写的理由是什么，是否因为某些需求不好解决或者临时性的需求变更，所以才这么做的？
2. 和对方沟通，告诉他你的临时解决方案，对我造成了很大的困扰。所以我们应该一起拿出一个更好的解决方案。
3. 不要觉得大家都是傻逼，自己是聪明人。职场上做的好人往往是你们看不起的傻子，而不是经常显摆自己很聪明的那种人。
4. 谦虚是一种很可贵的品德。项目是团队做出来的，不是一个人搞出来的。

[break]

别人没写过，有啥好喷的，你行你上啊。带带人家呗

[assassinpig]

有的就是重视说出来, 之后就没事了，谁能不错，错了还不能说才是问题
有的就是不能直接说粗来，怕伤了和气, 彼此以后不好再见面

[baoguok]

项目去求、接口定义，这些前期确定了，后面就按照文档开发，怎么会有频繁更改的问题。

很显然是公司没有流程，和写没写过接口无关

[mhycy]

@noli 不止应用层会抛 HTTP 状态码，依据不同的环境架构，有时候直接 200 使用 json 格式返回状态码会是更优的做法。

[learnshare]

老司机带带他，何必歧视小学生

[just4test]

我一般是对方同一个错误犯第三次开喷。

@mhycy “有时候直接 200 使用 json 格式返回状态码会是更优的做法。” 这点我一直不太明白用 body 返回状态码的优势所在。可以说明吗？

[zhoubug]

做些无啥含量的 REST 交互 无论前后台有啥资格互喷的。。。

[jucelin]

@just4test https://www.v2ex.com/t/191534 这个应该是他（@mhycy ）说的一种情况

[tyo]

@janstk 哈哈哈