REST API错误代码500处理

Question

我们正在构建一个新的REST API。

我认为永远不应该返回错误代码500（内部服务器错误）。

现在，当然，如果你知道客户端的参数是错误的，或者你控制了一切，并且可以返回一些适当的错误代码（例如422）。

因此，如果发生意外错误，服务器可以：

1. 不会捕获意外错误，以便500个气泡到客户端
2. 抓住任何意外错误并返回一些错误代码，表示“意外情况”（老实说，我找不到任何此类错误代码！）

还有其他选择吗？

Answer 1

这是服务器错误，而不是客户端错误。如果服务器错误没有返回给客户端，那么就不会为它们创建一个完整的状态代码类（即5xx）。

你无法隐瞒这样一个事实：你要么编程错误，要么你依赖的某些服务不可用，这当然不是客户的错。在这些情况下返回任何其他范围的代码而不是5xx系列是没有意义的。

RFC 7231 mentions in section 6.6. Server Error 5xx：

  

5xx（服务器错误）类状态代码表示服务器      知道它有错误或无法执行      要求的方法。

情况确实如此。什么都没有＆＃34;内部＆＃34;关于代码＆＃34; 500内部服务器错误＆＃34;从某种意义上说它不应该暴露给客户。

Answer 2

真正的问题是它为什么会产生500错误。如果它与任何输入参数有关，那么我认为它应该在内部处理并作为400系列错误返回。通常，400,404或406适合于反映错误输入，因为一般约定是由URL唯一标识RESTful资源，并且不能生成有效响应的URL是错误请求（400）或类似。

如果错误是由请求明确或隐式提供的输入以外的任何其他原因引起的，那么我会说500错误可能是合适的。因此，错误的数据库连接或其他不可预测的错误由500系列错误准确表示。

Answer 3

您建议“捕获任何意外错误并返回一些错误代码信号”意外情况“”但找不到合适的错误代码。

猜猜是什么：这就是5xx的用途。

Answer 4

一般来说，5xx响应代码表示非编程故障，例如数据库连接故障或某些其他系统/库依赖性故障。在许多情况下，预计客户可以在将来重新提交相同的请求并期望它成功。

是的，一些Web框架将使用5xx代码进行响应，但这些代码通常是代码中的缺陷导致的，并且框架太抽象而无法知道发生了什么，所以它默认为这种类型的响应;然而，这个例子并不意味着我们应该养成返回5xx代码的习惯，因为程序行为与进程外系统无关。有许多明确定义的响应代码比5xx代码更合适。无法解析/验证给定的输入不是5xx响应，因为代码可以容纳更合适的响应，不会让客户认为他们可以重新提交相同的请求，而实际上他们不能。

要明确的是，如果服务器遇到的错误是由CLIENT输入引起的，那么这显然是一个CLIENT错误，应该用4xx响应代码处理。期望客户端将更正其请求中的错误并重新提交。

然而，完全可以接受任何进程外错误并将其解释为5xx响应，但请注意，您还应在响应中包含更多信息以准确指出失败的错误;如果你可以包括SLA时间来解决问题，那就更好了。

我不认为将“意外错误”解释为5xx错误是一种好习惯，因为错误会发生。

这是一种常见的警报监视器，可以开始警告5xx类型的错误，因为这些通常表示系统出现故障，而不是失败的代码。所以，相应的代码！

Answer 5

80％的时间，这是由于 soapRequest.xml 文件

错误输入