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

[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":"用户名密码错误"}

[coosir]

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

[dobelee]

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

[dorothyREN]

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

[HeiXiaoBai]

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

[godruoyi]

@HeiXiaoBai 你咋不说是 `500` 呀

[godruoyi]

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

[godruoyi]

@dobelee 噢，

[godruoyi]

@coosir 噢，

[ic2y]

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

[alvin666]

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

[jlkm2010]

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

[MeteorCat]

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

[littleylv]

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

[gamexg]

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

[DCjanus]

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

[chotow]

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

[littlewing]

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

[blless]

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

[malusama]

验证错误不是 401?

[malusama]

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