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

[xderam]

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

[dongcclk]

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

[stormslowly]

那 graphql 怎么办？

[yhxx]

这样写很合理啊

[godruoyi]

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

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

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

[young6]

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

[hlwjia]

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

[scnace]

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

[yanaraika]

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

[FanError]

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

[yhxx]

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

[hcymk2]

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

[bk201]

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

[pkoukk]

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

[dallaslu]

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

[yanaraika]

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