Add extension element to Spring Web MVC @RequestMapping annotation [SPR-9153]

[spring-projects-issues]

Willie Wheeler opened SPR-9153 and commented

In web apps, it's useful to create a base CRUD controller and then extend that with entity-specific subclasses. This makes it easy to write general purpose HTML, XML and JSON endpoints. I typically define for each subclass a class-level @RequestMapping specifying the base path for that controller (e.g., /applications, /packages, /farms, etc). Then the method-level @RequestMappings have value = "" for list views, value = "/{id}" for details views, etc.

For the web service list views, I would like to be able to map paths like /applications.xml, /applications.json, etc. But it doesn't seem that I can do this without giving up the generality in the approach above. I'd have to drop the class-level @RequestMapping, write a bunch of wrapper methods on each subclass, and then annotate them with explicit @RequestMappings to get the desired paths. Blech. Instead, I just define a generic @RequestMapping in the base controller like this:

@RequestMapping(value = "", method = RequestMethod.GET, params = "format=json")
@RequestMapping(value = "", method = RequestMethod.GET, params = "format=xml")

That works, and it's generic, but I'd like to be able to use extensions instead, just because I think it's a little cleaner.

My proposal is that you add an extension element to the @RequestMapping. I envision it working something like this:

@RequestMapping(value = "", method = RequestMethod.GET, extension = "json")
@RequestMapping(value = "", method = RequestMethod.GET, extension = "xml")

Thanks.

---

Affects: 3.1.1

Issue Links:

• Content negotiation improvements [SPR-8410] #13057 Content negotiation improvements

[spring-projects-issues]

Rossen Stoyanchev commented

There is a plan for 3.2 to make the various options in ContentNegotiatingViewResolver work for @ResponseBody methods as well. The description of #13057 and its sub-tasks (plus related tickets) should provide a general idea.

What it may look like in the end is @RequestMapping(produces="application/json") along with some external configuration that associates ".json" with "application/json" and perhaps specifies that file extensions should be checked before the Accept header, etc. An extension attribute in @RequestMapping is an interesting idea to consider but we'll need to evaluate it against just having a produces condition.

I do need to fully understand the case you described. Would you mind creating a small project at the issues repo for it? That will be a good basis for this discussion and can be updated if necessary as a solution emerges in the nightly snapshot. The timing for this issue is perfect by the way!

[spring-projects-issues]

Willie Wheeler commented

Hey Rossen. From your response I think you are understanding my meaning.

The approach of using "produces", in tandem with that external configuration, is even better than mine: it's more in line with how the ContentNegotiatingViewResolver works, you avoid specifying JSON twice, and presumably the extension-to-media-type mapping could be externalized from the CNVR so that both views and @ResponseBody would use the same mapping.

I can't currently create the small project you're requesting, but I do have a GitHub project that shows what I'm talking about. See

https://github.com/williewheeler/skybase/blob/master/service/src/main/java/org/skydingo/skybase/web/controller/AbstractCrudController.java

and in particular the getListAsJson() and getListAsXml() methods. This class is a base controller for implementing entity-specific CRUD controllers. You can see that I'm forced to use params = "format=json" because there's no machinery for performing the mapping you mentioned.

[spring-projects-issues]

Rossen Stoyanchev commented

Okay, thanks for the link to the sample. That should do and I will have a look.

[spring-projects-issues]

Rossen Stoyanchev commented

This is now available in master and through a 3.2 snapshot. See the commit comments for more details.