在 REST 服务中将响应返回给客户端的所有可能性中,我已经看到了两种看似等效的可能性:抛出一个WebApplicationException(可能使用一个Response实例)或返回一个Response实例。
WebApplicationException
Response
由于结果相同,为什么要使用一种可能性而不是另一种?这是否与所使用的 REST 框架有关,可以将其配置为在异常和常规响应之间做出不同的反应?
由于结果相同,为什么要使用一种可能性而不是另一种?
也许因为作为(Java)程序员,您习惯于在应用程序的特定规则被破坏时引发异常?将一些字符串转换为数字,您可能会得到一个NumberFormatException,在数组中使用错误的索引,然后得到一个ArrayIndexOutOfBoundsException,访问某些您不允许访问的内容并获得一个SecurityExceptionetc。您习惯于在“常规响应”可以时抛出异常。无法创建(由于错误的输入或某些处理错误)。
NumberFormatException
ArrayIndexOutOfBoundsException
SecurityException
当您无法返回常规响应时,必须向客户端返回错误响应。您可以通过抛出异常或手动构建响应来实现。对于您的客户端来说,这是一回事,但对于服务器端代码而言,则是一回事。
引发异常可使您的代码更整洁,更易于推理,从而更易于理解 。这个想法是将其子类化,WebApplicationException并从中创建自己有意义的异常(例如ProductNotFoundException extends WebApplicationException { ... },AccessDeniedException extends WebApplicationException { ... }或者使用异常映射器重用异常)。
ProductNotFoundException extends WebApplicationException { ... }
AccessDeniedException extends WebApplicationException { ... }
这样,它对于throw new ProductNotFoundException()或throw new AccessDeniedException()让框架更干净,而不是Response每次都构建它,然后再遵循构建它的细节来弄清楚该代码部分中正在发生的事情。
throw new ProductNotFoundException()
throw new AccessDeniedException()