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

[tyo]

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

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

[noli]

@mhycy 你说的情况通常都是针对浏览器、 web 内容为主的应用，这种情况会需要担心网关和证书。 但对于 Restful API Client 来说，你可以指定要信任的少数证书，那么 HTTPS 是不可能被劫持的。在这种前提下，我们才可以无后顾之忧地讨论 API 设计。从这个基础开始出发，我来举例为什么总是保持 200 是不好的： HTTP 协议本身就已经工作在应用层，就是一个应用层协议，但是 HTTP 本身也有会话（ Session ）的概念，总是保持 200 会强迫不同协议层面（例如会话层）必须深入理解应用层协议才能决定如何处理会话。比如， HTTP 4XX 5XX 这种是一种很常见的足以让中间节点判断是否可以中断会话的信号，以及请求幂等性和结果缓存等等等优化。通通都用 200 来表示，莫非是打算叫 CDN 服务商帮忙写代码么。

[sueslee]

lower 是啥

[hcymk2]

@noli
别说那么多 ,去看下那些大厂是什么做的.
别太教条了.
你要先考虑下你的接口能不能被别人调用到再说. 你是没有碰到到有些只处理成功(200)的人

[noli]

@hcymk2 你贴的 Google 和 Amazon 的例子难道不就是 Http Status Code + Json 的好例子么？你从哪里看到他们告诉你返回的都是 200 ？

[hcymk2]

@noli
Google drive 例子 body 里面的 code 是什么?
s3 drive 例子 body 的 code 是什么?
不能只靠 HTTP response status codes
而且 google drive 是 HTTP error codes and messages in the header

[noli]

@hcymk2 对啊，所以只要被 Api 处理到了就返回 200 ，这不是大厂推荐的做法啊，保持返回 200 就是我反对的，你有什么意见吗？

[mhycy]

@noli
理性点看待问题，话不要说绝。
在 Web 场景下保持 200+JSON 响应消息这么设计是很合理的选择。
不要为了反对而反对，除非你能给出更优解。

套用知乎句式 “抛开场景谈设计就是耍流氓”

[changwei]

这个公司既然都是招这种水平的人，说明楼主入职之前对公司调研不够啊。

[Symo]

@noli 你对, 你有理, 你赢了.
开心吗, 满足了你的自尊心和虚荣心了嘛.

[noli]

@mhycy web 场景下我也没觉得 200+json 有什么特别的优势。当然啦，受制于国内的实际情况--很多 web 前端只是半桶水，不喜欢上 https 甚至 https 据说也被劫持--用 200+json 的好处也就就是能适应这种状况了，但非要说这是优势的话，我想起了这笑话: 中国人最大的特质是什么？贫穷。

[noli]

@Symo 觉得不屑与我讨论就请拉黑加屏蔽，众目睽睽之下拉坨屎你这是干嘛呢？好了，现在屎拉到我身上了，满足了你奇葩的虚荣心了吗？

[chairuosen]

@noli 如果你只用 HTTP STATUS CODE ，如果业务错误类型多于 HTTP STATUS 类型，而前端又想区分出错误类型，怎么办。

[noli]

@chairuosen 我没有说过只用 http status code 。我是反对，无论 api 如何处理 请求都返回 200 。

[chairuosen]

@noli 那就相当于有两个 code 字段了。 http status code 只是 json 中 code 的子集，所以前端肯定只用 json 中的 code ， http status 变成了冗余字段

[noli]

@chairuosen 只有不懂 rfc 威力的人才敢说 http status code 是冗余字段，理由我说了，全是 200 的话，你就别指望中间节点替你做进一步优化。再简单一点的例子，一堆客户端上为你做请求监控和警报的库也废掉了

[chairuosen]

@noli 这一点确实没考虑到

[mhycy]

@noli
我觉得已经没必要讨论下去了。
你这么说法完全就是为了反对而反对了。

[noli]

@mhycy 主要是你得出使用 200 + json 的结论依据，在我这里看来是说不通的：
你认为： 中间设备干扰 and HTTPS 也可能被劫持 and 非 200 HTTP 回复可能会被劫持，这是我从讨论中知道的你使用 200 + json 的理由。
我认为： 如果 HTTPS 都劫持，那么使用 200 + json 的做法，在大规模网络应用，是缺点多于优点。

我觉得确实没什么好讨论的，明摆着大厂都不用你的做法。
而如果你的业务够小，你喜欢怎么来当然都是 OK 的 --- 那不如更直接一点，直接在 80 端口上走自定义协议不是更好么，反正你也不需要 HTTP 的特别加持。

[mhycy]

@noli 请教缺点多于优点的缺点是啥

[noli]

@mhycy 总结 200 + json 对比较大规模 API 服务的缺点：
1. 对于会话层不友好：具体来说就是，譬如上面讨论说到的缓存控制， API 警报监控之类的应用，光这一点我觉得已经足够了。
2. 对于开发者不友好：如果使用你的 API 不仅仅是 web 端，还包括 移动端甚至别的端，那么你就要保证这些端都要有 解析 json 或者 xml 或者别的什么格式的能力，才能知道如何处理你的消息；这也意味着对更多的开发者来说，除了 HTTP 以外他们必须关注你的自定义格式，但是假如我仅仅是写一个小 demo ，我不关心出错信息，只想尽快跑通， json
+ 200 的做法，就给这种快速开发测试的需求制造了不必要的障碍。

事实上，如果你真的很关心浏览器使用 API 时受到的干扰，那么你完全可以用 open resty 之类的或者别的流水线，自己写一个简单的报文解析，根据 Agent 和 回复报文内容，将 Agent 是浏览器的 HTTP 回复 的 status 统一改成 200