Jersey REST API 中错误处理的最佳实践

Question

我已经使用 Jersey 1.9 返回 json 实现了 REST API，直到现在我还没有进行任何显式的错误处理，并且框架似乎可以很好地自行处理它。

现在我打算创建一个“应用程序”框架来更好地处理错误，我尝试寻找最佳实践，但没有找到任何

球衣文档： https://jersey.java.net/nonav/documentation/1.9/user-guide.html#d4e443

网上搜索很少： http://www.codingpedia.org/ama/error-handling-in-rest-api-with-jersey/

但我不喜欢这样，因为我们只是捕获所有异常格式并重新抛出，我认为它没有多大价值。

http://howtodoinjava.com/jersey/jax-rs-jersey-custom-exceptions-handling-with-exceptionmapper/ 我假设框架已经将未处理的异常处理为 500 响应代码，所以不要看到上面示例的重点。

此外，我还阅读了许多关于不同方法的讨论，其中即使发送错误条件并带有 200 响应，但它是空的，很少有人发送明确的代码，似乎没有“标准”，这导致我提出这个问题，寻求“专家”的最佳实践

Answer 1

与最终用户沟通错误是 API 设计的一个非常重要的部分。我建议使用 JAX-RS ExceptionMapper 机制来轻松地将异常映射到清除错误消息。

我喜欢将所有可以退出服务的异常分为两类。

客户端异常

这些异常 100% 是由用户输入引起的，并且服务没有可以避免它们。

例子：

• 凭据无效
• 缺少必需的参数
• 无效的 JSON 正文

它们应该以 4XX 错误代码的形式返回，并带有一条清楚说明问题原因并可能暗示解决方案的消息。

服务器端异常

这些异常 100% 是由应用程序的当前状态引起的，客户端无法避免它们。

例子：

• 数据库当前已关闭
• 临时网络问题
• 应用程序错误

它们应作为 5XX 错误代码返回，并带有一条消息，说明服务存在问题，客户端应稍后重试。这些都是严重的问题，需要尽快解决。

随着应用程序的成熟，您很可能会找到避免出现这些错误的方法。例如。通过在数据库不可用时回退到基于缓存的只读模式。

其他

应在您的应用程序逻辑中处理所有其他异常。如果不需要将它们传达给最终用户，则它们不应该有 ExceptionMapper，也不应该到达 Jersey 层。