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

[dunhanson]

我的个人的理解还是，这么做比较规范

但是同事的理解更多是优点好处是什么

比如用户登录错误之前的方式都是返回 http 状态码 200

{
  "code":4001001001,
  "message":"用户登录失败"
}

现在按照规范应该是，返回 http 状态码 401 ，然后 json 还是老样子

[0x49]

http status 仅用来判断系统是否有异常,业务的状态放 body 里

[wherewhale]

国内那会 care 这些 实用主义至上的氛围 远离这种业务团队吧

[MrSheng]

用 HttpCode 的能不秀优越么，甚至说出了阻碍技术进步的话，不觉得搞笑么？
来贴段代码让大家看看
talk is cheap,show me the code

[echo1937]

国内普遍 200+post 一把梭

[makelove]

用 http code 分类一下有这么难吗？
哪怕是在浏览器里，搞成一堆 200 成功请求难道要一个个打开内容去检查是不是有错误回应？

[daimubai]

我的做法是：
全 200 也不合适吧，通用的状态码应该保留

200 统一表示成功。
400 统一表示客户端参数错误、业务错误
401 没登录
403 没权限
404 接口不存在(一般 web 框架会处理。 如果请求的资源不存在不返回 404 的，比如用户不存在，就返回 400)
500 统一表示服务器异常

对于 200 ，响应体要不要包一层，可以再开一个贴子开撕，我的话是包的：{code:"0", message:"success",data:{}}

如果 400 或者 500 的话，返回{code: "-1" , message: ""}，-1 表示通用的业务异常，前端只需要取 message 弹窗即可。如果前端需要对业务异常进行逻辑判断，然后再自定义 code ，前端根据 code 去判断。


如果你的项目要做 saas ，给其他公司接，你也全 200 ？

[remember5]

@daimubai #46 想法一致

[hopingtop]

@daimubai 与你完全一致

[Freeego]

讲道理 http 状态码不是应用层的问题。全部用 http 状态码一个难以保证所有接口的返回结果都能找到对应的码，第二个难以区分是业务的问题还是更上层的传输的问题。我目前的做法是，对非 200 的返回直接显示系统异常，200 的再取里面的自定义状态码区分具体业务结果，只要有清晰的文档，这样完全没问题。

[WispZhan]

我就想问，说 200 一把梭的。是不做监控还是啥？

只能说野路子真多

[echo1937]

不要把 HTTP 状态码和业务码混为一谈，状态码不是用来代替业务码的，而是把内部信息暴露给外部的。

[Huelse]

http 状态码就是 http 状态，业务就是业务，不搞什么“大一统”，顶多就是第一位关联

[adoal]

@adoal 我这么说倒不是反对用 HTTP 状态码表示业务状态，而是说要想清楚以自己的团队和周边状态、项目背景、后续配套支持力度，甚至是组织机构设置、职权划分、撕逼流程，这样做是否真的能把事情做得更好，需要付出什么样的代价，做得更好的结果是否会引发其它可能的问题？工程上做选择都是 trade off ，有些看起来好的，能不能落地好是要结合实际的。

[yangyaofei]

"我们不吃(不用)那一套(已经定义好的状态), 要摸着石头过河(自己再定义一套一样的)", "都是国外用的玩具项目采用的", "又被卡脖子了, 真是亡我之心不死", "gayhub 不能上了"

矛盾不矛盾

[ClericPy]

如果平时不分析 nginx 日志, 不操心普罗米修斯做各种指标分析, 小公司爱咋咋的吧, 大厂的话, 技术评审感觉都过不去, 没必要和这些人争论.

不论对错, 只论适合不适合, 有些挣快钱的公司真的就是能用就行. 而且多数情况不怕做错, 怕的是不统一, 一错到底比有对有错带来的危害要小一点

你要做的大概不是来 V2EX 找认同, 而是提升自己然后尽早摆脱这种环境

[yangyaofei]

其实, 你看不看已经没用了, 两方的出发点(理论的基础)都是对方否定的. 所以再说也没用.

反正. "能用就行" 这种我是不敢用的, 必然会在能写屎山的地方写屎山, 简单的复合协议都不愿意做, 我不认为会写出好维护的代码.

手艺人都有手艺人自己的优雅和细致, 手艺人和大锤 50, 不一样.

[Biwood]

我认为这才是真正的“卷”。

最开始是运营商或搜索引擎根据 404 劫持页面，然后是网站服务方不得不全站 200 ，在然后形成了习惯、偷懒，美其名曰灵活、自定义规则，明明有 https 了却还是 200 一把梭。封闭文化始终存在与这个国家的方方面面，这根现在简体中文互联网整体的割裂基调是一致的。

V2EX 虽然有不少程序员，但是这个问题如果放到真正的技术网站，甚至根本都不应该成为一个问题。

[adoal]

至于拿监控说事的……监控啥？

如果是为了监控基础设施，我 JSON 里封的是业务逻辑层面的错误，关你基础设施屁事？

如果是为了监控业务错误，却嫌错误代码封在 JSON 里不方便……你就是想让我把业务错误代码放到 HTTP 里去对吧？你是不是觉得我这边各种各样的业务错误怎么映射到 HTTP 那几个状态码里很简单？你个普罗米修斯崽懂个屁的业务。

我的业务 API 又不只是为了让你来做监控而存在的，我要给别的业务单位调用啊。HTTP 状态码没出错，业务状态码出错的时候，可以去找管业务系统的人处理，HTTP 状态码出错了找管基础设施的人处理，这两拨人不是同样技能的啊。业务端有个什么狗屁错（而且还不是那种 unrecoverable 的外部环境错，是业务逻辑的错，要业务用户处理的）都返回成 HTTP 错误码一级一级传上去，查个业务级错误都要基础设施的人联动，这是制造民怨吗？你来给我做基础设施架构让我有办法一键定位出错的层次和节点吗？可是我只能拿到够做业务功能的经费，而且是单个单个项目做，没有做基础设施的条件，我让一个行业人士起家的地方性行业性中小型业务信息化开发商给我做业务系统开发的时候顺便免费做一套云原生的微服务的可观测的可这个那个狗屁的基础设施，并且以后的其它同类业务开发商要逼着他们不允许用自己的积累，一定要做在这些所谓现代的平台上，这忒外祖母的现实吗？

[libook]

401 指的是 Unauthorized ，是接口要求必须登录过才可以调用，不是登录失败。

HTTP 是有标准规范的，所有状态码都有定义。https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

需要注意的是：
1. 标准里对状态码的定义仅与 HTTP 协议通信的状态有关，跟业务无关，比如 401 仅代表 HTTP 协议层未认证，不代表业务上未认证，虽然有时候两者是同一件事。
2. 通用的 HTTP 客户端和服务器软件及其相关的框架和库都是会默认遵照 HTTP 标准规范来设计的，你可以不按标准使用，但你使用的软件、框架和库可能依然会按照标准来反应。
3. 有的 API 设计风格（如 REST ）会把业务状态和 HTTP 状态绑定一起，但这是建立在业务状态足够简单的基础上的，HTTP 状态码就那么多，无法把所有业务状态全映射到，比如登录失败可能有多种原因，客户端需要对不同原因进行判断再做反应，此时仅一个 400 状态码是没法解释清楚的。

建议先对 API 进行梳理，然后划分出哪些接口要用什么设计风格；对于可以遵照 HTTP 标准来设计的接口，需要去分别考虑每种返回情况的 HTTP 状态是什么、业务状态是什么，给出正确的 HTTP 状态，并在载荷中写明业务状态。

[adoal]

当然，我坚决反对 JDBC 连不上数据库服务器的时候抓出来异常还要包到 200 里向上返回……业务逻辑上的错误（责任在甲乙方最终用户，不涉及基础设施运维）用 200 包起来返回是一个美丑的问题，基础设施错误还要这么搞，是沙雕还是沙壁的问题。