你还在用 HTTP 200 状态码来返回错误响应吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› httpbin - 协议调试工具

› httpstatuses - 协议状态码查询

› httpie - cURL-like tool for humans

Fiddler

这是一个创建于 2270 天前的主题，其中的信息可能已经有所发展或是发生改变。

HTTP/1.1 200 OK
Server: nginx/1.14.0
Content-Type: application/json
Connection: keep-alive
Cache-Control: private, must-revalidate
Date: Tue, 09 Oct 2018 09:31:59 GMT
ETag: "974542d418f5a923b40fa1e01cba99b8d94216e1"
Content-Length: 62

{"code":-1,"msg":"用户名密码错误"}

36 条回复 • 2018-10-10 13:15:59 +08:00

coosir

2018-10-09 17:50:14 +08:00

现在这样做还是很普遍吧，很多公司并不会严格遵循 REST 风格
HTTP 状态码用来判断系统问题
JSON 里面的 code 用来判断业务问题

dobelee

2018-10-09 18:00:43 +08:00

同意楼上，不喜欢把系统问题和业务问题混为一谈，范式不是必须。

dorothyREN

2018-10-09 18:01:27 +08:00

没毛病啊，你请求的资源是成功的，所以返回 200 啊。

HeiXiaoBai

2018-10-09 18:05:44 +08:00 via Android

对啊，不然呢？你打算用哪个状态码？ 404 ？

godruoyi

2018-10-09 18:28:16 +08:00

@HeiXiaoBai 你咋不说是 `500` 呀

godruoyi

2018-10-09 18:29:10 +08:00

@dorothyREN 恩，你这样说我真的无言以对呢

godruoyi

2018-10-09 18:29:27 +08:00

@dobelee 噢，

godruoyi

2018-10-09 18:29:39 +08:00

@coosir 噢，

ic2y

2018-10-09 18:31:49 +08:00

不会严格按照 REST 风格，还是要封装一层业务 code，方便进行定制

alvin666

2018-10-09 18:31:58 +08:00 via Android

状态码不是 200 是系统出问题了，比如错误捕捉没写好，返回 500，这种情况就有很多可能了，然而只要请求成功，具体错误可以写的很清楚，比如说我一个请求有五十种状态，http 状态码哪里够？
别太杠，多学学

jlkm2010

2018-10-09 18:42:24 +08:00

正常返回数据，比如一个 user 信息,{id:1, name: "xx"}，状态码用 200-300 之间；
当出现错误时，http 状态码使用 400-600 之间的错误码，同时 response 里返回业务错误码和具体错误信息，比如{code: 1, msg: ""}
我一般这么设计

MeteorCat

2018-10-09 18:46:24 +08:00 via Android

同意一楼，服务器系统层面的错误码最好和 API 错误码区分开

littleylv

2018-10-09 18:47:39 +08:00

200 没毛病，确实请求成功了。
其他业务错误码就用返回 json 里的 code

gamexg

2018-10-09 18:51:37 +08:00

听说有运营商、设备会劫持非 200 的响应，
虽然现在流行 https，但是还是有一些是 http 会中招。

DCjanus

2018-10-09 18:52:38 +08:00 via Android

范式统一就好了，又没什么优劣之分。
很多人吹 RESTful，却没看过 REST 原始论文，不理解为什么那样设计，只能在细枝末节上做原教旨主义者。

chotow

2018-10-09 19:35:14 +08:00 via Android

用户名密码错误，我会用 400 错误。

littlewing

2018-10-09 19:43:54 +08:00

正常，为什么一定要遵循范式？
就比如数据库表的设计，很多时候反范式才是最好的设计

blless

2018-10-09 19:50:49 +08:00 via Android

这里只是把 http 当业务承载层而已吧，本质上其实就是 rpc 啊，RESTful 实现起来真的麻烦…

malusama

2018-10-09 19:54:18 +08:00

验证错误不是 401?

malusama

2018-10-09 19:55:34 +08:00

用状态码和响应信息并不矛盾把? 401 也可以带详细信息啊

xderam

2018-10-09 20:18:47 +08:00

http code 状态码确实不多能用得上就用，用不上别强求就 ok 了。当年设计 http code 的时候或许没考虑到也考虑不到那么多五花八门的业务逻辑。所以不要硬上~

dongcclk

2018-10-09 20:58:52 +08:00 via iPhone

现在在用 RESTful 风格。
但是下次设计时不会再用了，会统一用 200 状态加错误码。错误码根据业务逻辑设计。

stormslowly

2018-10-09 22:25:45 +08:00

那 graphql 怎么办？

yhxx

2018-10-09 22:33:52 +08:00

这样写很合理啊

godruoyi

2018-10-09 22:45:12 +08:00

还在觉得上面的设计很合理的同学，建议参考下下面这两篇文章

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

https://godruoyi.com/posts/resetful-api-design-specifications

young6

2018-10-09 23:24:37 +08:00

RESTful 确实有点毛病，详见下文
https://mmikowski.github.io/the_lie/

hlwjia

2018-10-09 23:52:38 +08:00

规矩都是人定的，规矩是死的，人是活的。

scnace

2018-10-10 00:58:55 +08:00 via Android

这种情况我会用 403 一般的 webapi 请求错误我会用 400 这样能很好地区分到底是哪里出现了问题 (也方便甩锅) 当然 rpc 就另说了(

yanaraika

2018-10-10 05:52:27 +08:00

结果某一天你的服务全挂了，中间件因为根据状态码监控认为一切正常就没报警，第二天起来损失了一个亿

FanError

2018-10-10 09:06:09 +08:00 via iPhone

@yanaraika 中间件不能根据内容中的 code 监控吗？

yhxx

2018-10-10 09:17:21 +08:00

@godruoyi 阮老师说的“最佳实践”未必就是最佳实践

hcymk2

2018-10-10 10:30:55 +08:00

@FanError
一个服务无所谓。关键是要有统一的规范。要不你得让运维开发一套适配各种情况的监控插件。

bk201

2018-10-10 10:47:13 +08:00

@FanError 那监控代码就复杂了,既要监控狀態码,又要监控自定义 code,一旦非标准自定义的 code 有修改,又要跟着改动.
其实自定义 code 最大的问题在于维护,而标准不需要维护,因为这就是标准,一看就知道哪里出了问题.

pkoukk

2018-10-10 11:02:56 +08:00

业务上的错误消息远远比 http 状态码多多了，不够用啊

dallaslu

2018-10-10 11:33:01 +08:00

如果你说你是 RESTful，最好还是严格遵循范式；如果你不遵循，那请说你是类 RESTful 并列出设计不同之处。这样既满足业务，又不会有歧义。

yanaraika

2018-10-10 13:15:59 +08:00

@FanError 公司会有 N 种业务，每种用不同的方式来汇报错误码，infra team 表示想自杀