@ResponseBody usage limitations [SPR-7278]

[spring-projects-issues]

Gerrit Brehmer opened SPR-7278 and commented

The recommended way to develop REST-style webservices is the usage of @ResponseBody annotation and HttpMessageConverter instead of generating a model and a view (ContentNegotiatingViewResolver etc.).
But there are some limitations, that make things hard to handle:

• ExceptionResolver support
  • @RequestBody is only supported with @ExceptionHandler annotation. I need a centralized exception handling to generate a special error object as the return value. So I must wrote a method in each controller class to delegate to the centralized exception handler. I think the ExceptionResolver-interface is more like an AOP-approach, with no glue code.
  • ExceptionResolver also have some nice standard implementations like SimpleMappingExceptionResolver, where I can handle the returned HTTP status code very easy. This is also not supported by @ExceptionHandler out of the box
• 'useNotAcceptableStatusCode' from ContentNegotiatingViewResolver (so for some features, I must also configure view-handling)
  • simple and easy to use attribute to enable NOT_ACCEPTABLE Http Status code
• missing option for enabling global @ResponseBody-like handling instead of annotate all methods (e.g. in AnnotationMethodHandlerAdapter)

I also would recommend the full HttpMessageConverter way (@RequestBody & @ResponseBody) without view handling, so it would be nice, if @ResponseBody has fewer limitations. Additionaly it would be great, if the documentation have some notes about the recommended way for webservice-only REST-style applications (with hints to the limitations above)

---

Affects: 3.0.2

Issue Links:

• @ExceptionHandler doesn't handle exceptions from other controllers [SPR-8124] #12776 @ExceptionHandler doesn't handle exceptions from other controllers ("is duplicated by")
• Add equivalent of JAX-RS @Produces to Spring MVC [SPR-7353] #12012 Add equivalent of JAX-RS @Produces to Spring MVC

Referenced from: commits e5eceaf

1 votes, 2 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

For handling exceptions centrally I would recommend implementing HandlerExceptionResolver. Even though it's less convenient than @ExceptionHandler, if you want to use @RequestBody and @ResponseBody, you can still use HttpMessageConverters and by definition you won't have too many of these methods.

As for assuming @RequestBody and @ResponseBody by default, have a look or track #13053.

[spring-projects-issues]

Gerrit Brehmer commented

I searched for a way to minimize the use of the ModelAndView-concept. HandlerExceptionResolver depends on the concept and @ExceptionHandler can not replace the standard resolver implementations adequate. Yes, #13053 is one part of my proposal. So I assume that more concrete enhancement requests would help you to improve the webservice-only. I will think about it.

[spring-projects-issues]

Rossen Stoyanchev commented

The DefaultHandlerExceptionResolver is similar to your description. It translates exceptions into status codes and doesn't rely on view resolution and always returns an empty ModelAndView.

Also we can consider an extension hook in the new ExceptionHandlerExceptionResolver, which would allows customizations to the list of @ExceptionHandler methods associated with a controller type:

protected void extendExceptionHandlerMethods(List<Method> methods, Class<?> handlerType) {
}

A subclass of ExceptionHandlerExceptionResolver would then have a chance to add @ExceptionHandler methods that apply to every controller.

[spring-projects-issues]

Rossen Stoyanchev commented

The above mentioned extension method is now available.

[spring-projects-issues]

Gerrit Brehmer commented

Thanks. I will check this out with the next version.