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

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

@mhycy 我知道在使用劣质 CA 签发的证书的情况下 HTTPS 可以等于没有，但排除这种情况之后， HTTPS 是无法劫持的。即使是存在劣质 CA 这样情况，因为存在 HTTPS 劫持的缘故多花时间重新做一套本来解决 HTTP Status code 就足以解决的问题，依然是不值得的。并且，如果连 HTTPS 劫持都做得出来，你觉得我们讨论在 JSON 里面放 400 还是用 HTTP Status 来放 400 什么的，这些还有意义吗？

@mhycy 你说的不就是 明文 HTTP 被中间设备篡改内容 而已嘛。担心这个，上 HTTPS 才是正途，而不是在 API 上面搞什么自主创新，开发者的时间重新发明轮子来处理这个问题根本就是浪费时间。

@mhycy 你说的原则我很同意。但我觉得 Http Status 比 Json 或者别的什么格式表示的 status 更“通用”，更简单更暴力更少歧义。任何一个合格 Http Client 都肯定能解析得出这个 http status 。

@mhycy 考虑的设备更多应用涉及的规模越大才更应该好好地使用 Http 状态码，毕竟 http 状态码是 RFC 上定义的而你自己定义的状态码只是你的什么鬼文档里定义的。 试图在一个庞大系统中的单点解决所有问题，这是想得太多，优化太早。

@mhycy 但是 4XX 错误肯定不是环境的问题啊，更进一步，如果不是协议上的问题而是例如连接问题，你扔个 200 过去也不能保证客户端能正确接收

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

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

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

这有什么，我今天喷了一个 Android 兼职过来写 php 后台不懂什么叫 Http Status Code 的家伙。
能用 400 Bad Request 解决问题非要返回一个字符串或者 json 的。
反正又不是我发工资，我喷他为毛呢。

当然，我的重点其实是想说 php 是最好的语言。

用得很高兴，虽然有很多 issue ，但是相信开源软件力量会解决这些 issue ，感谢作者的贡献

别找借口了，键盘手感和码代码有一定关系但并不是那么大。或许对你来说确实影响很大，但那么多顶尖程序员，你看他们有多少是用什么著名品牌键盘？

消费主义在你的思想中打下了钢印，然而黑客的武器是思想而不是键盘。

@xfspace 请问这样搭 VPN 是绕道国内（较快的）线路连海外服务器吗？

忽略我上面的回复吧，感觉我理解错问题了。

如果只是想判断是不是完全一样，那么可以对 list 中的字典内容进行 hash ，比较 hash 值。如果还想知道哪个字典值不一样，那么可以用 merkle tree 的思想

@game3108 只是一种经验或者感觉，用 os 或者 unix 的观点去解构和重组 iOS 的很多概念都是行得通的

unix 原理是让一切不成体系的 iOS 知识点串联变成体系的关键

@jin6220 任何集合与空集的交集，结果都是空集。