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

2018 年 10 月 9 日
 godruoyi
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":"用户名密码错误"}
9486 次点击
所在节点    HTTP
36 条回复
xderam
2018 年 10 月 9 日
http code 状态码确实不多 能用得上就用，用不上别强求就 ok 了。 当年设计 http code 的时候或许没考虑到也考虑不到那么多五花八门的业务逻辑。所以不要硬上~
dongcclk
2018 年 10 月 9 日
现在在用 RESTful 风格。
但是下次设计时不会再用了，会统一用 200 状态加错误码。错误码根据业务逻辑设计。
stormslowly
2018 年 10 月 9 日
那 graphql 怎么办？
yhxx
2018 年 10 月 9 日
这样写很合理啊
godruoyi
2018 年 10 月 9 日
还在觉得上面的设计很合理的同学，建议参考下下面这两篇文章

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

https://godruoyi.com/posts/resetful-api-design-specifications
young6
2018 年 10 月 9 日
RESTful 确实有点毛病，详见下文
https://mmikowski.github.io/the_lie/
hlwjia
2018 年 10 月 9 日
规矩都是人定的，规矩是死的，人是活的。
scnace
2018 年 10 月 10 日
这种情况我会用 403 一般的 webapi 请求错误我会用 400 这样能很好地 区分到底是哪里出现了问题 (也方便甩锅) 当然 rpc 就另说了(
yanaraika
2018 年 10 月 10 日
结果某一天你的服务全挂了，中间件因为根据状态码监控认为一切正常就没报警，第二天起来损失了一个亿
FanError
2018 年 10 月 10 日
@yanaraika 中间件不能根据内容中的 code 监控吗？
yhxx
2018 年 10 月 10 日
@godruoyi 阮老师说的“最佳实践”未必就是最佳实践
hcymk2
2018 年 10 月 10 日
@FanError
一个服务无所谓。关键是要有统一的规范。要不你得让运维开发一套适配各种情况的监控插件。
bk201
2018 年 10 月 10 日
@FanError 那监控代码就复杂了,既要监控狀態码,又要监控自定义 code,一旦非标准自定义的 code 有修改,又要跟着改动.
其实自定义 code 最大的问题在于维护,而标准不需要维护,因为这就是标准,一看就知道哪里出了问题.
pkoukk
2018 年 10 月 10 日
业务上的错误消息远远比 http 状态码多多了，不够用啊
dallaslu
2018 年 10 月 10 日
如果你说你是 RESTful，最好还是严格遵循范式；如果你不遵循，那请说你是类 RESTful 并列出设计不同之处。这样既满足业务，又不会有歧义。
yanaraika
2018 年 10 月 10 日
@FanError 公司会有 N 种业务，每种用不同的方式来汇报错误码，infra team 表示想自杀

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/496047

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX