@ResponseBody [SPR-5766]

[spring-projects-issues]

Kenny MacLeod opened SPR-5766 and commented

It seems odd and undesirable that the annotation-style of MVC controllers should only make use of HttpMessageConverter on the request, and not the response. Specifically, @RequestBody -annotated arguments can be resolved using HttpMessageConverter .read(), but there's no support for rendering the response using HttpMessageConverter .write().

This is addressed to some degree in #10100, but I'm focussing here more on writing elegant REST controllers; the controller should be able to take the typed and unmarshalled request body Object, and should be able to return a similarly type Object for marshalling. The ModelAndViewResolver approach suggested in #10100 just doesn't seem right.

Would it be possible for the standard return value resolution logic to consult with any HttpMessageConverters in the context, as happens with @RequestBody annotations? There doesn't seem to be a need for a @ResponseBody annotation.

---

Affects: 3.0 M3

Issue Links:

• Allow for custom processing or result objects returned from handler/controller methods [SPR-5426] #10100 Allow for custom processing or result objects returned from handler/controller methods

[spring-projects-issues]

Arjen Poutsma commented

Well, if we are going to use HttpMessageConverters, we do definitely need a explicit annotation to trigger it. This is due to the fact that @Controllers can return a String or 'simple value type' (URL, Date, Number, Locale, etc), to be interpreted as view name or model object respectively.

[spring-projects-issues]

Arjen Poutsma commented

Edit the title and replaced HttpMethodConverter with HttpMessageConverter.

[spring-projects-issues]

Kenny MacLeod commented

How about changing AnnotationMethodHandlerAdapter so that it can be configured with two sets of HttpMessageConverters, one for @RequestBody annotations, and one for method return values? The latter can be blank by default, and so retains current behaviour, but you could wire it up with a message converter for handling return values, if you so choose.

[spring-projects-issues]

Arjen Poutsma commented

Hmm, I am not a big fan of having two sets of HttpMessageConverters. The idea for the message converters is that they work out of the box for common 'machine-to-machine' REST types, like byte[], XML, JSON (forthcoming), etc. If you write your own converter, it should be usable in both request and response scenario's, on both client and server side. For server-side request/response-specific scenarios we already have the WebArgumentResolver and ModelAndViewResolver.

Another underlying issue is that return type resolution is already quite complex, and on the verge of being ambiguous, considering all the different return type variants you can have, and also considering the fact that the method name can be significant too. This makes the Spring code for handling these quite hard to understand already, and supporting message converters for return types would make it even harder. Unfortunately, refactoring this code is not an option, because we have to maintain backwards compatibility.

Therefore, the main reason for introducing a new, supplemental annotation like @ResponseBody would be to decrease this ambiguity: using this annotation would mean that you use message converters, and not the defaults.

I know this is not a very strong argument: it mostly comes down to a matter of taste, and Spring Framework internals. But I do think having a separate @ResponseBody annotation is the best way forward.

[spring-projects-issues]

Kenny MacLeod commented

OK, I'm cool with that. Perhaps, for consistency with @ResponseStatus, the @ResponseBody annotation could have attributes which indicate where the response body should be taken from, specified as an enum, defaulting to the method return value. I'm not sure what other possibilities there would be, mind you.

[spring-projects-issues]

Arjen Poutsma commented

Done!

[spring-projects-issues]

Kenny MacLeod commented

Great stuff. I see that the annotation is defined as only allowed on methods... could it be allowed on the controller class also, indicating that all methods "inherit" it?