你还在用 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 条回复
coosir
2018 年 10 月 9 日
现在这样做还是很普遍吧，很多公司并不会严格遵循 REST 风格
HTTP 状态码用来判断系统问题
JSON 里面的 code 用来判断业务问题
dobelee
2018 年 10 月 9 日
同意楼上，不喜欢把系统问题和业务问题混为一谈，范式不是必须。
dorothyREN
2018 年 10 月 9 日
没毛病啊，你请求的资源是成功的，所以返回 200 啊。
heixiaobai
2018 年 10 月 9 日
对啊，不然呢？你打算用哪个状态码？ 404 ？
godruoyi
2018 年 10 月 9 日
@HeiXiaoBai 你咋不说是 `500` 呀
godruoyi
2018 年 10 月 9 日
@dorothyREN 恩， 你这样说我真的无言以对呢
godruoyi
2018 年 10 月 9 日
@dobelee 噢，
godruoyi
2018 年 10 月 9 日
@coosir 噢，
ic2y
2018 年 10 月 9 日
不会严格按照 REST 风格，还是要封装一层业务 code，方便进行定制
alvin666
2018 年 10 月 9 日
状态码不是 200 是系统出问题了，比如错误捕捉没写好，返回 500，这种情况就有很多可能了，然而只要请求成功，具体错误可以写的很清楚，比如说我一个请求有五十种状态，http 状态码哪里够？
别太杠，多学学
jlkm2010
2018 年 10 月 9 日
正常返回数据，比如一个 user 信息,{id:1, name: "xx"}，状态码用 200-300 之间；
当出现错误时，http 状态码使用 400-600 之间的错误码，同时 response 里返回业务错误码和具体错误信息，比如{code: 1, msg: ""}
我一般这么设计
MeteorCat
2018 年 10 月 9 日
同意一楼，服务器系统层面的错误码最好和 API 错误码区分开
U7Q5tLAex2FI0o0g
2018 年 10 月 9 日
200 没毛病，确实请求成功了。
其他业务错误码就用返回 json 里的 code
gamexg
2018 年 10 月 9 日
听说有运营商、设备会劫持非 200 的响应，
虽然现在流行 https，但是还是有一些是 http 会中招。
DCjanus
2018 年 10 月 9 日
范式统一就好了，又没什么优劣之分。
很多人吹 RESTful，却没看过 REST 原始论文，不理解为什么那样设计，只能在细枝末节上做原教旨主义者。
chotow
2018 年 10 月 9 日
用户名密码错误，我会用 400 错误。
littlewing
2018 年 10 月 9 日
正常，为什么一定要遵循范式？
就比如数据库表的设计，很多时候反范式才是最好的设计
blless
2018 年 10 月 9 日
这里只是把 http 当业务承载层而已吧，本质上其实就是 rpc 啊，RESTful 实现起来真的麻烦…
malusama
2018 年 10 月 9 日
验证错误不是 401?
malusama
2018 年 10 月 9 日
用状态码和响应信息并不矛盾把? 401 也可以带详细信息啊

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

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

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

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

© 2021 V2EX