HTTP 500 表示服务器由于意外原因无法满足请求。当服务器因已知或预期原因无法满足请求时，使用什么最佳 HTTP 响应代码？
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
查看一些关于 HTTP 的文档，我找不到好的答案，这似乎是一个重要的区别。为并不真正代表“内部服务器错误”的错误抛出 500 可能不是一个好的做法。
最佳答案
不要再使用 RCF 2616 作为引用
RFC 2616 如今已不再适用，任何使用此类文档作为引用的人都应该立即停止。引用 Mark Nottingham在撰写本文时，谁是 IETF HTTP 和 QUIC 工作组的联合主席:
Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out.
旧的 RFC 2616 已被以下文档所取代，这些文档共同定义了 HTTP/1.1 协议(protocol):
如果您正在寻找状态代码定义，那么 RFC 7231是您应该引用的文档。
什么是已知或预期的原因？
根据已知或预期的原因，您可以返回正确的状态代码:
- 无法完成请求，因为客户正在请求不存在的资源？返回
404. - 是授权问题吗？去寻找
403. - 使用HTTP authentication凭据无效？返回
401. - 服务器不支持满足请求所需的功能吗？使用
501. - 由于与目标资源的当前状态冲突，请求无法完成？所以
409应该归还。 - 是否为目标资源分配了一个新的永久 URI？
301状态码是正确的选择。 - 等等...
决策图
有关更多详细信息，请查看 RFC 7231并查看以下 decision chart那Michael Kropat放在一起:
状态码大致分为三类:
从这里开始:
选择2xx和3xx状态码
选择4xx状态码
选择5xx状态码
关于 "could not fulfill request for *known* reason"的 HTTP 状态代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33815690/