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":"用户名密码错误"}
1
coosir 2018-10-09 17:50:14 +08:00
现在这样做还是很普遍吧,很多公司并不会严格遵循 REST 风格
HTTP 状态码用来判断系统问题 JSON 里面的 code 用来判断业务问题 |
2
dobelee 2018-10-09 18:00:43 +08:00
同意楼上,不喜欢把系统问题和业务问题混为一谈,范式不是必须。
|
3
dorothyREN 2018-10-09 18:01:27 +08:00 1
没毛病啊,你请求的资源是成功的,所以返回 200 啊。
|
4
HeiXiaoBai 2018-10-09 18:05:44 +08:00 via Android
对啊,不然呢?你打算用哪个状态码? 404 ?
|
5
godruoyi OP @HeiXiaoBai 你咋不说是 `500` 呀
|
6
godruoyi OP @dorothyREN 恩, 你这样说我真的无言以对呢
|
9
ic2y 2018-10-09 18:31:49 +08:00
不会严格按照 REST 风格,还是要封装一层业务 code,方便进行定制
|
10
alvin666 2018-10-09 18:31:58 +08:00 via Android 1
状态码不是 200 是系统出问题了,比如错误捕捉没写好,返回 500,这种情况就有很多可能了,然而只要请求成功,具体错误可以写的很清楚,比如说我一个请求有五十种状态,http 状态码哪里够?
别太杠,多学学 |
11
jlkm2010 2018-10-09 18:42:24 +08:00 3
正常返回数据,比如一个 user 信息,{id:1, name: "xx"},状态码用 200-300 之间;
当出现错误时,http 状态码使用 400-600 之间的错误码,同时 response 里返回业务错误码和具体错误信息,比如{code: 1, msg: ""} 我一般这么设计 |
12
MeteorCat 2018-10-09 18:46:24 +08:00 via Android
同意一楼,服务器系统层面的错误码最好和 API 错误码区分开
|
13
littleylv 2018-10-09 18:47:39 +08:00
200 没毛病,确实请求成功了。
其他业务错误码就用返回 json 里的 code |
14
gamexg 2018-10-09 18:51:37 +08:00 1
听说有运营商、设备会劫持非 200 的响应,
虽然现在流行 https,但是还是有一些是 http 会中招。 |
15
DCjanus 2018-10-09 18:52:38 +08:00 via Android
范式统一就好了,又没什么优劣之分。
很多人吹 RESTful,却没看过 REST 原始论文,不理解为什么那样设计,只能在细枝末节上做原教旨主义者。 |
16
chotow 2018-10-09 19:35:14 +08:00 via Android 1
用户名密码错误,我会用 400 错误。
|
17
littlewing 2018-10-09 19:43:54 +08:00
正常,为什么一定要遵循范式?
就比如数据库表的设计,很多时候反范式才是最好的设计 |
18
blless 2018-10-09 19:50:49 +08:00 via Android
这里只是把 http 当业务承载层而已吧,本质上其实就是 rpc 啊,RESTful 实现起来真的麻烦…
|
19
malusama 2018-10-09 19:54:18 +08:00
验证错误不是 401?
|
20
malusama 2018-10-09 19:55:34 +08:00
用状态码和响应信息并不矛盾把? 401 也可以带详细信息啊
|
21
xderam 2018-10-09 20:18:47 +08:00
http code 状态码确实不多 能用得上就用,用不上别强求就 ok 了。 当年设计 http code 的时候或许没考虑到也考虑不到那么多五花八门的业务逻辑。所以不要硬上~
|
22
dongcclk 2018-10-09 20:58:52 +08:00 via iPhone
现在在用 RESTful 风格。
但是下次设计时不会再用了,会统一用 200 状态加错误码。错误码根据业务逻辑设计。 |
23
stormslowly 2018-10-09 22:25:45 +08:00
那 graphql 怎么办?
|
24
yhxx 2018-10-09 22:33:52 +08:00
这样写很合理啊
|
25
godruoyi OP |
26
young6 2018-10-09 23:24:37 +08:00
RESTful 确实有点毛病,详见下文
https://mmikowski.github.io/the_lie/ |
27
hlwjia 2018-10-09 23:52:38 +08:00 1
规矩都是人定的,规矩是死的,人是活的。
|
28
scnace 2018-10-10 00:58:55 +08:00 via Android
这种情况我会用 403 一般的 webapi 请求错误我会用 400 这样能很好地 区分到底是哪里出现了问题 (也方便甩锅) 当然 rpc 就另说了(
|
29
yanaraika 2018-10-10 05:52:27 +08:00
结果某一天你的服务全挂了,中间件因为根据状态码监控认为一切正常就没报警,第二天起来损失了一个亿
|
33
bk201 2018-10-10 10:47:13 +08:00
@FanError 那监控代码就复杂了,既要监控狀態码,又要监控自定义 code,一旦非标准自定义的 code 有修改,又要跟着改动.
其实自定义 code 最大的问题在于维护,而标准不需要维护,因为这就是标准,一看就知道哪里出了问题. |
34
pkoukk 2018-10-10 11:02:56 +08:00 1
业务上的错误消息远远比 http 状态码多多了,不够用啊
|
35
dallaslu 2018-10-10 11:33:01 +08:00
如果你说你是 RESTful,最好还是严格遵循范式;如果你不遵循,那请说你是类 RESTful 并列出设计不同之处。这样既满足业务,又不会有歧义。
|