关于接口返回 Status Code 是否都应该为 200 的问题

[m939594960]

我编写接口的时候 Status Code 并没有都返回 200 有部分 422 401 等等。

在跟 IOS 对接的时候出现了一些问题，IOS 那边非常不赞同我这种返回的方式，希望我都返回 200，然后他们那边根据状态码进行判断，说返回 422 401 等非 200 状态码的返回数据处理起来比较麻烦（他们 使用的 AFNetworking 库）

然后我这边就查阅了很多国内的网站提供的接口，淘宝、美团、微博等等确实都是返回的 200 并没有按照具体错误返回不同的 Status Code，而且返回的 body 里也没有携带 Status Code

问下究竟应不应该按照不同情况返回不同情况的 Status Code，还是应该在返回 json 中返回具体错误码（在不考虑网络劫持的情况加）

[Livid]

很多 CDN 对于内容是否能够被缓存，状态码也是考虑因素之一。

[ty89]

曾经不要 b 脸的某米路由器还会拦截 404/5xx 的状态

建议：统一返回 200，然后在数据包里自己约定一些状态码，比如 {status: 10001, data: {...}, msg: '' }

[hand515]

服务器收到并处理了建议还是返回 200。

[m939594960]

@Livid 我思考了一下，没太明白，能麻烦详细解释一下么？

[m939594960]

@ty89 #2 接口都上了 https 应该不太用考虑这块

[SuperMild]

Status Code 本来是一种通用的约定，方便不同的客户端与服务端交流，写客户端的人可以默认收到 200 就正常处理，收到 4XX、5XX 就进行异常处理。如果是面对不同人群的公开 API，最好按照通用约定去做。

但是公司内部使用的、非对外的 API，的确可以按自己的方便来变通处理。

[bazingaterry]

如果用状态码，可能业务情景会和服务器状态有重叠，例如说用 500 你不清楚是后端挂了还是业务逻辑上的错误。如果统一 200，出现了 500 那就基本确保后端挂了。

[asen477]

CDN 的问题，我想是通过状态来决定内容是否被缓存。
至于状态返回建议统一请求成功反状态码 200

[DCjanus]

我们这一般是不统一返回 200
这样线上监控和翻日志都比较方便，毕竟可以根据状态码找异常的部分
当然，你也可以统一返回 200 然后自己在逻辑里写好 log，能达到同样的效果，只是我比较懒所以……

[m939594960]

@asen477 #8 关于 cdn 的问题，错误的反 422 400 什么的不会被缓存，200 的有可能被缓存，这样也没有什么问题么？一般返回 422 400 什么的应该都是请求的参数有些问题缓存下来也没有什么意义啊

[m939594960]

@bazingaterry #7 我觉得不是很容易出现这种和服务器状态有重叠的问题，一般 500 错误只在程序有很致命的错误 才能返回的状态码吧，正常情况下我逻辑的返回 基本都是 400 ～ 500 之间的状态码，一般情况下 nginx 或者 apache 应该不会主动返回这类的状态码吧

[lygmqkl]

除了 200， 我非常喜欢使用 400，401，403，404

建议使用 200，400，401，403，404 and 500

[lygmqkl]

不过国内程序员的各种各样的怪毛病也只能见怪不怪了，

[m939594960]

@lygmqkl #12 我这个接口也是这样的，不会用很偏僻的状态码 都是这些非常常见的。 但是看国内大厂的接口都没用这种的

[ooTwToo]

有规范还是按规范来吧，满足不了需求还可以往 response 塞 errorinfo 呀。

[lygmqkl]

@m939594960 国情而已 习惯就好了，简单的说就是 google 和 baidu 的区别

当然国内也有很多优秀的程序员，只是你没遇到而已。