为什么要区分不同的 http 状态码？想说服同事

@bobo2
错误日志 Debug 日志，都有日志层统一处理，各开发语言都有这样的框架。你不能指望错误日志去 Nginx 的 Log 看吧？

很多人把状态码和业务码混淆来说了，首先 HTTP 状态码理所应当交给服务器去判断，这次请求到底是 200 还是 400 还是 500 ，难道你要在代码里因为业务问题，恰巧这个业务问题像是 400 请求参数错误，所以我给客户端返回个 400 ，看！你因为主观的判断修改了 HTTP 状态码，此刻它已经不纯粹了它到底代表 HTTP 请求的状态还是你业务的一种场景已经区分不了啊，所以业务码它就是业务码，HTTP 状态码就应该让服务器本身去决策

再返回楼主的例子，它是一个登录错误，OK, 登录错误有很多种服务未授权 [类似于在黑名单] 、token 失效、秘钥不匹配，此时难道都要以 401 去返回给客户端么，那么这个 401 到底代表什么？倒不如定义一种业务码未授权比如是 1001 ，token 失效是 1002 、秘钥不匹配 1003, HTTP 状态码依然是 200, 为什么是 200 因为本次的请求是成功的它是服务表述的状态，而登录的未授权需要根据场景返回对应的业务码。个人理解

问就是 post 200 一把梭

都可以，全局统一就行了

RESTful 一时爽，nginx log 统计拆路径、状态码火葬场

我说两点，
1. 把 code 放 body 里，除非 body 又是一个自定义的超文本协议，像 json 这种文本“协议”（包含通用 code ，data 可以理解为一种协议了）没法包非文本数据（你 base64 编码下当我没说）
2. 如果需要根据 code 动态序列化 data ，那反序列化要 2 次完成

而 http 本身就是超文本协议，body 可以是文本，也可以是图片等二进制数据，status code 是在 header 里，而且是简单的基于行的协议，不需要反序列化就可以读取 status code ，根据条件解析 body

除了 4** 其他的真的是不适合用，而且不包括 404
你 404 了，谁知道是 API 端口没了还是没 query 到

测了下各大公司情况 v2ex.com/t/846785

基于 httpcode 来实现的状态管理，我们的扩展性如何？
比如 502 ，就是服务器挂了呀，然后再在这上面加个业务含义。
怎么玩呢？

联想到了吗，对 HTTP 是否应该使用状态码来表达业务状态的争议，其实颇像「使用异常还是错误码」这个同样老生常谈的问题。有些人大小事都要抛异常；另一些人尝试 catch 一切异常，并永远使用错误码。而当代码要接入一个现有模块时，事情变得更复杂了。

HTTP 通用的错误码（ 4xx, 5xx ）很有限，就像系统定义的异常类型，必然无法涵盖所有错误的情况。但我们不必做二极管，始终在上面提到的两种人间反复横跳：尽管很多错误码是和 HTTP 协议强相关的（比如 411 ），至少常用的 401/403/404 语义可以完美对应项目中一定会出现的几种错误情况；除此之外，简单用 400 表达请求有问题，500 表达服务端有问题，搭配自定义的错误代码即可。

另一个和是否使用 HTTP 错误状态码相似的争议，是「是否要以 REST 方式组织 API 」。是的，生搬硬套的 CRUD 语义没办法定义现实中的所有复杂情况，但也不该因此就彻底抛弃这套被广泛接受的代码组织思路：GET 不应有副作用，PUT 相比 POST 有幂等性；实在不行把一些操作都抽象成某个 Action ，然后所有有副作用的操作一律 POST 也比一团乱麻来得整洁。

没什么好说的, 全是 200, 返回的数据必包含 code, 根据 code 判断.
好处是错误码可以自定义 n 多个. Http 状态码才几个.

{"code":-1001, "msg":"登录失败, 用户名或密码错误"}
{"code":0, "msg":"ok","data":{"user":{"name":"test"}}}

盲猜，肯定有添狗说，国内不懂规范，国外严格遵守。并举例说，不遵守引发的问题。。

先用 http 状态码，业务上能行就继续。不能行自然就转了 200 一把梭了。我司是后者。

最大的转折点在于 httpcode 的数量太少无法应对复杂的业务状态。

说个很简单的，一个是别人已经制定好的规则，一个是自己制定的规则，使用一个就行，两个都用不行。
前端后端都是自己做的话，哪个方便就哪个。

http 状态码数量太少，只能用于对出错情况进行分类
具体的错误还是需要使用业务状态码再次拆分
并且，http 状态码每种只用一个（ 2xx ，4xx ，5xx ）自定义的跟服务器返回的不冲突，这样也可以区分到底是服务器出问题还是业务出问题，至少可以解决接入监控的问题

面试面了几个，有外包经验的基本都是 200 一把梭。。。。简单来说就是图省事。
但凡规范化一点的，都是要区分几种基本的状态码。
200 ，400 ，401 ，403 ，500 等， 具体细化各有差别。还有说 http 状态只是给浏览器看的， 简直 2

@afewok 恭喜你，猜对了，可惜没有奖励

个人倾向成功使用 2xx ；失败用 4xx 、5xx ，以 application/problem+json 格式表示异常信息