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

Question

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

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

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

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

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

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 层。