我们正在构建一个新的 REST API。
我认为永远不应该返回错误代码 500（内部服务器错误）。
现在，当然，如果您知道客户端的参数有误，或者您可以控制一切，并且可以返回一些适当的错误代码（例如 422）。
因此，如果发生意外错误，服务器可以：
还有其他选择吗？
【问题讨论】：
标签： api rest http error-handling error-code
这是服务器错误，而不是客户端错误。如果不将服务器错误返回给客户端，则不会为它们创建完整的状态代码类（即 5xx）。
您无法隐瞒您犯了编程错误或您依赖的某些服务不可用的事实，这当然不是客户的错。在这些情况下返回 5xx 系列以外的任何其他范围的代码都是没有意义的。
RFC 7231 mentions in section 6.6. Server Error 5xx:
5xx（服务器错误）类状态码表示服务器 意识到它有错误或无法执行 请求的方法。
情况正是如此。代码“500 Internal Server Error”没有任何“内部”意义，它不应该暴露给客户端。
【讨论】：
真正的问题是它为什么会产生 500 错误。如果它与任何输入参数有关，那么我认为它应该在内部处理并作为 400 系列错误返回。通常 400、404 或 406 适合反映错误输入，因为一般约定是 RESTful 资源由 URL 唯一标识，而无法生成有效响应的 URL 是错误请求 (400) 或类似的。
如果错误是由请求显式或隐式提供的输入以外的任何其他原因引起的，那么我会说 500 错误可能是合适的。因此，数据库连接失败或其他不可预知的错误可以准确地表示为 500 系列错误。
【讨论】：
一般而言，5xx 响应代码表示非编程故障，例如数据库连接故障或其他一些系统/库依赖项故障。在很多情况下，期望客户端可以在未来重新提交相同的请求并期望它成功。
是的，一些 web 框架会响应 5xx 代码，但这些通常是代码缺陷的结果，并且框架太抽象而无法知道发生了什么，所以它默认为这种类型的响应；然而，这个例子并不意味着我们应该习惯于返回 5xx 代码作为与进程外系统无关的编程行为的结果。有许多定义明确的响应代码比 5xx 代码更合适。无法解析/验证给定的输入不是 5xx 响应，因为代码可以容纳更合适的响应，不会让客户认为他们可以重新提交相同的请求，而实际上他们不能。
需要明确的是，如果服务器遇到的错误是由于 CLIENT 输入引起的，那么这显然是一个 CLIENT 错误，应该使用 4xx 响应代码来处理。期望客户将更正其请求中的错误并重新提交。
但是，捕获任何进程外错误并将其解释为 5xx 响应是完全可以接受的，但请注意，您还应该在响应中包含更多信息以准确指出失败的原因；如果您可以包含 SLA 时间来解决，那就更好了。
我认为将“意外错误”解释为 5xx 错误并不是一个好习惯，因为会发生错误。
这是一个常见的警报监视器，用于开始对 5xx 类型的错误发出警报，因为这些错误通常表示系统失败，而不是代码失败。所以，相应地编码！
【讨论】：
您建议“捕获任何意外错误并返回一些错误代码表示“意外情况””，但找不到合适的错误代码。
猜猜看：这就是 5xx 的用途。
【讨论】：
80% 的情况下，这可能是由于 soapRequest.xml 文件中的错误输入
【讨论】：