API 状态返回 code 1 好还是直接用 http status?

[Phishion]

感觉用 code 1 什么的有点鸡肋，还不如直接用 http 状态 2xx 就是成功

[michaelcheng]

说不准，公司业务里是没有直接用 http status, 自己定义了自己的响应规范

[casztg]

看公司的习惯来把，HTTP 协议是套规范，一切以实际为准。

[killerv]

如果业务比较复杂，http code 可能不够用

[TommyLemon]

HTTP 协议里定义了 status 和 message，
但是都是在 Response Header 里返回的，设置和查看都不方便，
所以一般就和数据一起封装到 Response body 里了

[owenliang]

依靠 HTTP 状态码表达的方式，属于 REST API 范围。

一般 open api 采用 REST，公司内 RPC 与公司内 client 与 server 一般不完全遵守 REST，也就是统一 200 表示正常，并用 payload 里的 errno 之类的表达错误。

[sorshion]

标准 restful 推荐用 http 状态码，自己定义的，统一就好

[ChristopherWu]

http code 2xx, 5xx，3xx 只是表明了这个 http 请求的状况如何，与你的业务没有挂钩。

http 请求可以成功，不代表业务成功了，所以你的业务需要制定另外的一套状态码，来与前端沟通此业务操作的状况。（不是儿戏的项目都需要，对吧？）

[ChristopherWu]

另外如果你的业务状态码与 http 状态码 重合，也不是 best practice.
很容易在沟通上出现误会。

[huiyue]

API 返回结果如果涉及业务，不建议用 http status 来。

[duxinglangzi]

我认为单纯的讲 API 返回的 code 字段值，还是自定义的比较好。http status 是表示网络访问状态。我觉得和业务上的 code 码最好不要 混在一起，不好分辨。 另外可以参考一下 腾讯微信公众号文档设计规则。

[HuHui]

返回一个 404 呢？

[zpfhbyx]

业务模块 id+http 响应码 100200 这种- -，

[sampeng]

我更倾向有明确符合 http 协议的。用 http 头里的 status。再结合 body 力的 status 表示更多的含义。。。
比如 401.这个错误。再结合 body 里的 status。就能明确是客户端错误。
有些客户端只用处理 4XX 的就行了。其他的 5XX 的直接返回错误信息就好了。不用做太多处理。
如果是只有 body 的 status。所有的都得判断。。对客户端挺不友好的。

关键是从语义上更清晰一点。

[MeteorCat]

按需求来选择 rest，最怕 nginx 排查的时候一堆奇怪的响应码

[swcat]

http code 表示网络状态，接口是业务层的，最好不要混用，
有可能 http code 不够用
而且想过运营商劫持非成功响应吗🤣，


当然具体情况具体分析，如果是内部用，都不存在的，这种东西约定好就行

[yujieyu7]

从逻辑上来讲，http 状态码是来标识 http 请求状态的，就不要把业务状态强加进去了，这完全是两个领域的事情。

另外，复杂业务下，那状态码根本不够用呐。

事实上绝大部分公司还是用自己定义的业务码来返回的 api 调用情况的。阿里 api，百度 api 等等，无一例外

[leafiy]

逻辑上讲怎么都对，实际情况是 3 楼，比如 409 就不够用的。。。。

[xcstream]

code 200 表示正常

[jianpanxia]

一起用.

[whileFalse]

作为运维提一句，我们在负载均衡器层做了 http status code 的统计。4xx 5xx 我们会统计出来给到开发检查业务问题。
如果开发用 4xx 表达正常业务信息……嗯那是他们自己的事儿我们也管不着。