在 RESTful API 中返回 HTTP 500 是否合适？

Question

当我编写 RESTful API 服务器时，通常我不会在代码中返回 HTTP 500。\n在我看来，HTTP 500 错误意味着\xef\xbc\x9a

\n\n

某些超出您控制范围的情况/异常。你没有意识到可能会发生错误

\n\n

如果您意识到可能会发生某些错误，您总是可以找到其他一些 HTTP 代码来表示它。例如503。

\n\n

所以我不想手动返回 HTTP 500。在这种情况下，如果发生 500，那么我知道这是一些未处理的异常

\n\n

这是一个好的做法吗？

\n

Answer 1

在 RESTful API 中返回 HTTP 500 是否合适？

我不会说它很好，但我会说它是有效的。

请务必记住，状态代码旨在表示服务器尝试理解并满足客户端请求的结果。您可以在RFC 7231中阅读有关状态代码的更多信息，但简而言之，这就是 HTTP 状态代码根据其范围的含义：

• 1xx： 坚持，稍等
• 2xx： 干得好
• 3xx： 离开
• 4xx: 你搞砸了
• 5xx: 我搞砸了

如果服务器未能满足明显有效的请求，最好返回该5xx范围内的状态代码，而不是用另一个可能导致客户端混乱的状态代码掩盖实际错误。如果客户端请求有效，则不要返回2xx或 范围内的状态码。4xx

所以我不想手动返回 HTTP 500。

根据应用程序的体系结构，您可能希望有一个层来捕获任何未处理的异常并将其转换为状态代码。根据异常情况，您可能希望返回该5xx范围内的状态代码。

您可能还会发现在响应中返回某种与日志相关的标识符很有用，因此它可以帮助您发现应用程序发生了什么。

Answer 2

在 RESTful API 中返回 HTTP 500 是否合适？

没关系。 500 内部服务器错误具有广泛适用的语义。

我认为关键的想法是：当问题出在服务器上时，客户端（或中间组件）可以做很多事情来改善这种情况。

当然，当错误出现在请求中时，您不应该使用 500 状态代码。区分 4xx 和 5xx 比区分 500 和 50x 重要得多。

For server errors, I would expect you to choose 500 unless some other code were a clearly better fit (ex: 503 for temporary conditions where Retry-After semantics are likely to prove useful).