Spring Framework
  1. Spring Framework
  2. SPR-8406

Create separate handler stereotype for RESTful web services

    Details

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

      Description

      The @Controller stereotype is tailored for a role within an MVC environment. As such, it makes certain assumptions that are not completely valid in a web services scenario (for instance, implicit view name resolution, and the ModelAndView concept).

      We could add another stereotype (eg. @Resource) that suits a web service scenario better. For instance, it would not (implicitly) use the ModelAndView paradigm, and default to having @Request- and @ResponseBody on all methods.

        Issue Links

          Activity

          Hide
          Rossen Stoyanchev added a comment -

          You can have any number of HandlerExceptionResolver instances. For view controllers, it's also common to use SimpleMappingExceptionResolver.

          Show
          Rossen Stoyanchev added a comment - You can have any number of HandlerExceptionResolver instances. For view controllers, it's also common to use SimpleMappingExceptionResolver.
          Hide
          Michael Osipov added a comment - - edited

          OK, that feasible through the DispatcherServlet config. If I do register two handlers where each handles View and ResponseEntity and I do throw a NoSuchRequestHandlingMethodException from a ViewController and a ResponseEntityController how am I supposed to detect that in my HandlerExceptionResolver. Obviously that part of the Spring documenation does not reveal this secret to me. Again, I miss the big picture here.
          The big problem with most HandlerExceptionResolvers is that they use sendError and the container must contruct an error page as per Servlet spec. This is unwanted in REST API. This is what I am struggling with.

          Show
          Michael Osipov added a comment - - edited OK, that feasible through the DispatcherServlet config. If I do register two handlers where each handles View and ResponseEntity and I do throw a NoSuchRequestHandlingMethodException from a ViewController and a ResponseEntityController how am I supposed to detect that in my HandlerExceptionResolver . Obviously that part of the Spring documenation does not reveal this secret to me. Again, I miss the big picture here. The big problem with most HandlerExceptionResolvers is that they use sendError and the container must contruct an error page as per Servlet spec. This is unwanted in REST API. This is what I am struggling with.
          Hide
          Rossen Stoyanchev added a comment -

          > how am I supposed to detect that in my HandlerExceptionResolver.

          That's where the setMappedHandlers property I mentioned above comes in.

          > The big problem with most HandlerExceptionResolvers is that they use sendError and the container must contruct an error page as per Servlet spec.

          There is not much we can do about that. Even the response status is set to a 4xx or 5xx status (instead of sendError), without a body, Servlet containers can still send an HTML error page. You can customize the default servlet container error page or make sure the response body has some error content.

          Show
          Rossen Stoyanchev added a comment - > how am I supposed to detect that in my HandlerExceptionResolver. That's where the setMappedHandlers property I mentioned above comes in. > The big problem with most HandlerExceptionResolvers is that they use sendError and the container must contruct an error page as per Servlet spec. There is not much we can do about that. Even the response status is set to a 4xx or 5xx status (instead of sendError), without a body, Servlet containers can still send an HTML error page. You can customize the default servlet container error page or make sure the response body has some error content.
          Hide
          Rossen Stoyanchev added a comment -

          Resolving as "Won't Fix" as simply introducing a new stereotype in itself doesn't provide sufficient benefit. We can instead focus on making concrete improvements in support of applications built for humans vs for an automated client as we did with the introduction of a ResponseEntityExceptionHandler, global @ExceptionHandler methods, the ContentNegotiationStrategy and ContentNeogtiationManager, and others in Spring Framework 3.2.

          Show
          Rossen Stoyanchev added a comment - Resolving as "Won't Fix" as simply introducing a new stereotype in itself doesn't provide sufficient benefit. We can instead focus on making concrete improvements in support of applications built for humans vs for an automated client as we did with the introduction of a ResponseEntityExceptionHandler , global @ExceptionHandler methods, the ContentNegotiationStrategy and ContentNeogtiationManager , and others in Spring Framework 3.2.
          Hide
          Michael Osipov added a comment -

          How am I supposed to detect that in my HandlerExceptionResolver?

          That's where the setMappedHandlers property I mentioned above comes in.

          As far as I can see, that method is located in the AbstractHandlerExceptionResolver but the argument is not generic, so what input types are allowed.

          Eventhough, if this one accepts controllers, I would not be able to handle everything under a path like /rest unless I define a fake RestControlller, I guess.

          Show
          Michael Osipov added a comment - How am I supposed to detect that in my HandlerExceptionResolver? That's where the setMappedHandlers property I mentioned above comes in. As far as I can see, that method is located in the AbstractHandlerExceptionResolver but the argument is not generic, so what input types are allowed. Eventhough, if this one accepts controllers, I would not be able to handle everything under a path like /rest unless I define a fake RestControlller, I guess.

            People

            • Assignee:
              Rossen Stoyanchev
              Reporter:
              Arjen Poutsma
              Last updater:
              Michael Osipov
            • Votes:
              12 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 20 weeks ago