@RequestMapping should support accept header and url extension [SPR-6497]

[spring-projects-issues]

Paul Bakker opened SPR-6497 and commented

Sometimes it's necessary to execute different code to setup a model for a different type of content.
For example; a list of employees should be returned directly for rendering HTML, but should be wrapped in a JAXB class for rendering XML, as in the following example.

@RequestMapping(value = "/list.html") //Doesn't work for accept header!
public ModelAndView listHTML(HttpServletRequest request) {

    ModelAndView mav = new ModelAndView();
    mav.addObject("employees", employeeDao.listEmployees());
    return mav;
}

@RequestMapping(value = "/list.xml") //Doesn't work for accept header!
public ModelAndView listXML(HttpServletRequest request) {
    ModelAndView mav = new ModelAndView();
    mav.addObject("employees", new EmployeeList(employeeDao.listEmployees()));

    return mav;
}

There seems to be no easy way at this moment to apply this. Of course you could use the headers parameter in the @RequestMapping, but that doesn't work when a request is done without the accept header using an extension in the url instead (e.g. list.xml). When using an url extension as in the above example it doesn't work when only the accept header is set.

JAX-RS has a @Produces and @Consumes annotation which does the job perfectly. Wouldn't we need something similar in Spring?

---

Affects: 3.0 RC2

Issue Links:

• Add content-negotiation to RequestBody and ResponseBody processing [SPR-6993] #11658 Add content-negotiation to RequestBody and ResponseBody processing ("is duplicated by")
• @RequestMapping should support alternative between a header and a url extension [SPR-7722] #12378 @RequestMapping should support alternative between a header and a url extension ("is duplicated by")
• Spring MVC - Ability to use a Converter based on the Path Extension instead of Accep Header. [SPR-8546] #13190 Spring MVC - Ability to use a Converter based on the Path Extension instead of Accep Header. ("is duplicated by")
• Content negotiation improvements [SPR-8410] #13057 Content negotiation improvements ("is superseded by")

3 votes, 3 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

Although 3.1 already has a "produces" condition in @RequestMapping, currently it works of the 'Accept' header only. A more comprehensive update in this area is planned for 3.2 (see #13057).

[spring-projects-issues]

Rossen Stoyanchev commented

This is now resolved. To configure detecting requested media types through URL path extensions, declare a ContentNegotiationManager bean and use it in the RequestMappingHandlerMapping (for matches via the produces condition), the RequestMappingHandlerAdapter and the ExceptionHandlerExceptionResolver (for writing to the response body).