客户端 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也只会降低用户的体验而不是改善用户的体验。因为最终用户大部分时候都只能知道错了，但不知道错在哪里。
当然是很个人的看法，欢迎任意批判。