客户端 POST 错误,服务端应该回 200 还是 400?

刚好今天和一个同事在这个问题上意见不一。

于是翻到了知乎上的这个问题,遗憾的是下面的答案都很水,没有一个深得我心。这很有可能证明我的看法是片面的,管它呢。但它激起了我的表达欲望,我于是键盘侠了下面这一篇。刚好傻子知乎嫌弃我没有认证国内手机号,不让我发表。那我就给自己的 Blog 添块砖吧。

其实这个标题蛮误导人。Post 错误....这种表述再宽泛了。因此有人支持有人反对都不奇怪。多么 Bad 的 Request 算Post错误?每个人有每个人的出发点,这太难达成一致了。

我的观点缩成一句话,只要请求使用 Api 协议(参数个数类型都)正确,我接受甚至有点喜欢响应 200 OK 再给出具体的 ErrorCode 和 ErrorMessage 这种做法。 既然请求能抵达你的 Action 处理方法,至少说明发起请求的一方是有一点点诚意的。如果你再有一点点时间,即使请求不是十全十美,给个不等于0的ErrorCode和一个合理的ErrorMessage是一种绅士的做法。

如果请求格式合法,服务器能够理解,但不能给出满意的结果,或者说 errorCode 不是0的情况,我个人的实践的是返回 200,并给出具体的错误码和错误信息。理由是这个请求不是无效的和非法的,直接扔400 是给前端增加工作量。

即使现在在的框架已经内置了 NotFound() 之类的快捷响应办法, 但只要Route正确到达了我的处理方法,而我又不想偷懒,我的观点也是应尽量给出人类能够理解的出错信息。你总不能因为商品暂时缺货就直接甩404吧!

我不赞成甚至讨厌那些把2xx - 5xx那几十个code 一个个或合理或牵强附会的对号入座,毕竟发明大部分这些Code 的时候还根本没有 Restful 概念。它们都过于宽泛了,是给喜欢偷懒和甩锅的程序员们准备的。即使你使用的前端框架能够自动帮你处理这些code,广泛而大量的使用这些code也只会降低用户的体验而不是改善用户的体验。因为最终用户大部分时候都只能知道错了,但不知道错在哪里。

当然是很个人的看法,欢迎任意批判。