Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.2
    • Fix Version/s: None
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      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)

        Issue Links

          Activity

          Hide
          Rossen Stoyanchev added a comment -

          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 SPR-8406.

          Show
          Rossen Stoyanchev added a comment - 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 SPR-8406 .
          Hide
          Gerrit Brehmer added a comment -

          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, SPR-8406 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.

          Show
          Gerrit Brehmer added a comment - 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, SPR-8406 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.
          Hide
          Rossen Stoyanchev added a comment -

          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.

          Show
          Rossen Stoyanchev added a comment - 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.
          Hide
          Rossen Stoyanchev added a comment -

          The above mentioned extension method is now available.

          Show
          Rossen Stoyanchev added a comment - The above mentioned extension method is now available.
          Hide
          Gerrit Brehmer added a comment -

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

          Show
          Gerrit Brehmer added a comment - Thanks. I will check this out with the next version.

            People

            • Assignee:
              Rossen Stoyanchev
              Reporter:
              Gerrit Brehmer
              Last updater:
              Trevor Marshall
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 44 weeks, 3 days ago