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/ 我假设unhandeled异常已经被框架作为500响应代码处理,所以不要看上面的例子.

此外,我读了许多关于不同方法的讨论,其中甚至错误条件以200响应发送但是空的并且很少人发送显式代码,似乎没有"标准"并且这导致我提出这个问题,寻求最佳实践"专家"

Answer 1

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

我喜欢做的是将可以在两个类别下退出服务的所有异常分组.

客户端异常

这些例外是100%所造成的用户输入并没有什么服务可以做,以避免它们.

例:

• 无效证件
• 缺少必需参数
• 无效的JSON正文

它们应作为4XX错误代码返回,并带有明确解释问题原因并可能暗示解决方案的消息.

服务器端异常

这些异常是100%由应用程序的当前状态引起的,客户端无法做任何事情来避免它们.

例:

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

它们应作为5XX错误代码返回,并显示一条消息,说明服务存在问题,客户端应稍后重试.这些是严重的问题,需要迅速解决.

随着您的应用程序的成熟,您很可能会找到避免诉诸这些错误的方法.例如,当数据库不可用时,回退到基于高速缓存的只读模式.

其他

应在您的应用程序逻辑中处理所有其他异常.如果它们不需要与最终用户通信,则它们不应该具有ExceptionMapper,并且不应该到达Jersey层.