REST API 错误代码 500 处理
REST API error code 500 handling
我们正在构建一个新的 REST API。
我在争论错误代码 500（内部服务器错误）不应该 returned。
现在，当然，如果您知道客户端的参数是错误的或者您可以控制一切，并且可以 return 一些适当的错误代码（例如 422）。
因此，如果发生意外错误，服务器可能：
- 不捕获意外错误，以至于 500 个冒泡到客户端
- 捕获任何意外错误和 return 一些错误代码，发出 "unexpected situation" 信号（老实说，我找不到任何此类错误代码！）
还有其他选择吗？
这是服务器错误，不是客户端错误。如果服务器错误不返回给客户端，就不会为它们创建完整的状态代码 class（即 5xx）。
您无法隐瞒您的编程错误或您依赖的某些服务不可用的事实，这当然不是客户的错。在这些情况下，返回 5xx 系列之外的任何其他代码范围都没有意义。
RFC 7231 mentions in section 6.6. Server Error 5xx:
The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the
requested method.
正是如此。代码“500 Internal Server Error”在不应暴露给客户端的意义上没有任何“内部”内容。
真正的问题是它为什么会产生 500 错误。如果它与任何输入参数相关，那么我认为它应该在内部处理并作为 400 系列错误返回。通常 400、404 或 406 适合反映错误输入，因为一般惯例是 RESTful 资源由 URL 和无法生成有效响应的 URL 唯一标识是错误请求 (400) 或类似请求。
如果错误不是由请求显式或隐式提供的输入引起的，那么我认为 500 错误可能是合适的。因此，数据库连接失败或其他不可预测的错误准确地表示为 500 系列错误。
一般来说，5xx 响应代码表示非编程失败，例如数据库连接失败或其他一些 system/library 依赖项失败。在很多情况下，期望客户端可以在以后重新提交相同的请求并期望成功。
是的，一些网络框架会以 5xx 代码响应，但这通常是代码缺陷的结果，框架太抽象以至于不知道发生了什么，所以它默认为这种类型的响应；但是，该示例并不意味着我们应该养成返回 5xx 代码的习惯，作为与进程外系统无关的编程行为的结果。有许多定义明确的响应代码比 5xx 代码更合适。无法 parse/validate 给定输入不是 5xx 响应，因为代码可以提供更合适的响应，不会让客户认为他们可以重新提交相同的请求，而事实上，他们不能。
需要说明的是，如果服务器遇到的错误是由于客户端输入造成的，那么这显然是一个客户端错误，应该使用 4xx 响应代码进行处理。期望客户将更正其请求中的错误并重新提交。
然而，捕获任何进程外错误并将其解释为 5xx 响应是完全可以接受的，但请注意，您还应该在响应中包含更多信息以准确指出失败的原因；如果您可以包括 SLA 时间来解决，那就更好了。
我认为将 "an unexpected error" 解释为 5xx 错误不是一个好习惯，因为错误时有发生。
开始对 5xx 类型的错误发出警报是一种常见的警报监视器，因为这些错误通常表示系统出现故障，而不是代码出现故障。因此，相应地编码！
您建议"Catching any unexpected errors and return some error code signaling "意外情况“ ”，但找不到合适的错误代码。
猜猜看：这就是 5xx 的用途。
80% 的情况下，这是由于 soapRequest.xml 文件
中的错误输入造成的
我们正在构建一个新的 REST API。
我在争论错误代码 500（内部服务器错误）不应该 returned。
现在，当然，如果您知道客户端的参数是错误的或者您可以控制一切，并且可以 return 一些适当的错误代码（例如 422）。
因此，如果发生意外错误，服务器可能：
- 不捕获意外错误，以至于 500 个冒泡到客户端
- 捕获任何意外错误和 return 一些错误代码，发出 "unexpected situation" 信号（老实说，我找不到任何此类错误代码！）
还有其他选择吗？
这是服务器错误，不是客户端错误。如果服务器错误不返回给客户端，就不会为它们创建完整的状态代码 class（即 5xx）。
您无法隐瞒您的编程错误或您依赖的某些服务不可用的事实，这当然不是客户的错。在这些情况下，返回 5xx 系列之外的任何其他代码范围都没有意义。
RFC 7231 mentions in section 6.6. Server Error 5xx:
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.
正是如此。代码“500 Internal Server Error”在不应暴露给客户端的意义上没有任何“内部”内容。
真正的问题是它为什么会产生 500 错误。如果它与任何输入参数相关，那么我认为它应该在内部处理并作为 400 系列错误返回。通常 400、404 或 406 适合反映错误输入，因为一般惯例是 RESTful 资源由 URL 和无法生成有效响应的 URL 唯一标识是错误请求 (400) 或类似请求。
如果错误不是由请求显式或隐式提供的输入引起的，那么我认为 500 错误可能是合适的。因此，数据库连接失败或其他不可预测的错误准确地表示为 500 系列错误。
一般来说，5xx 响应代码表示非编程失败，例如数据库连接失败或其他一些 system/library 依赖项失败。在很多情况下，期望客户端可以在以后重新提交相同的请求并期望成功。
是的，一些网络框架会以 5xx 代码响应，但这通常是代码缺陷的结果，框架太抽象以至于不知道发生了什么，所以它默认为这种类型的响应；但是，该示例并不意味着我们应该养成返回 5xx 代码的习惯，作为与进程外系统无关的编程行为的结果。有许多定义明确的响应代码比 5xx 代码更合适。无法 parse/validate 给定输入不是 5xx 响应，因为代码可以提供更合适的响应，不会让客户认为他们可以重新提交相同的请求，而事实上，他们不能。
需要说明的是，如果服务器遇到的错误是由于客户端输入造成的，那么这显然是一个客户端错误，应该使用 4xx 响应代码进行处理。期望客户将更正其请求中的错误并重新提交。
然而，捕获任何进程外错误并将其解释为 5xx 响应是完全可以接受的，但请注意，您还应该在响应中包含更多信息以准确指出失败的原因；如果您可以包括 SLA 时间来解决，那就更好了。
我认为将 "an unexpected error" 解释为 5xx 错误不是一个好习惯，因为错误时有发生。
开始对 5xx 类型的错误发出警报是一种常见的警报监视器，因为这些错误通常表示系统出现故障，而不是代码出现故障。因此，相应地编码！
您建议"Catching any unexpected errors and return some error code signaling "意外情况“ ”，但找不到合适的错误代码。
猜猜看：这就是 5xx 的用途。
80% 的情况下，这是由于 soapRequest.xml 文件
中的错误输入造成的