As proposed by @rstoyanchev, here is a draft PR that allow to provide hints without implementing Request/ResponseBodyAdvice. I have used an Object source parameter to allow using this mechanism for the HTTP client and the server functional programming model if need, without exposed MethodParameter in the codec/reader/writer API.

Any thoughts?

Comment From: rstoyanchev

This looks simple enough but for JSONP and for HTTP ranges (very likely) we'll also need access to the request. At that point however it is no longer symmetric between client and server and only applies to the server.

Perhaps a variation on this PR could be a ServerHttpMessageWriter that extends HttpMessageWriter and has the extra method to resolve hints? On the implementation side it would be one or more hint resolving wrappers (e.g. JsonView, JSONP, etc) in the end delegating the actual writing to the target, underlying HttpMessageWriter (e.g. the one with the Jackson2JsonEncoder).

This would allow all places to still accept an HttpMessageWriter but at writing time also check if they're an instance of ServerHttpMessageWriter. We can automatically add the wrappers on startup in the WebReactiveConfiguration and there is no need for an additional configuration option.

Comment From: sdeleuze

@rstoyanchev Good points, I will update the PR accordingly.

Comment From: sdeleuze

@rstoyanchev I have pushed updated commits, could you please have a look?

Comment From: rstoyanchev

In addition to moving to spring-web I see two more things to improve.

There is no way to apply more than one of these (e.g. JsonView + JSONP). Perhaps instead of extending DecoderHttpMessageWriter we should have an AbstractServerHttpMessageWriter that delegates to another HttpMessageWriter. And if the delegate happens to be an ServerHttpMessageWriter it would allow the delegate to also add hints.

Two this doesn't yet cover the case of the HttpMessageWriterView which is a View that writes through an HttpMessageWriter. This would have been relatively simple to do until recently after the change to View to accept a Map rather than HandlerResult. @poutsma not sure what the answer is. On a first thought perhaps a HandlerResultView extension of View with a method that accepts HandlerResult instead of just a model? So the ViewResolutionResultHandler can then check and prefer to invoke the render with a HandlerResult if available. We need some way to pass the extra information when it is available.

Comment From: poutsma

Two this doesn't yet cover the case of the HttpMessageWriterView which is a View that writes through an HttpMessageWriter. This would have been relatively simple to do until recently after the change to View to accept a Map rather than HandlerResult. @poutsma not sure what the answer is. On a first thought perhaps a HandlerResultView extension of View with a method that accepts HandlerResult instead of just a model? So the ViewResolutionResultHandler can then check and prefer to invoke the render with a HandlerResult if available. We need some way to pass the extra information when it is available.

To be honest, I never really understood the need for the HttpMessageWriterView in the first place, but perhaps I am missing something. What does it do that a @ResponseBody cannot do?

Comment From: sdeleuze

Indeed + that allows to use that mechanism with the SSE reader/writer too.

I have updated the commit accordingly, is it ok for you (not sure if the remaining point you raised about HttpMessageWriterView impact this PR or not, I guess we will see depending on @poutsma feedback) ?

Comment From: rstoyanchev

To be honest, I never really understood the need for the HttpMessageWriterView in the first place, but perhaps I am missing something. What does it do that a @ResponseBody cannot do?

Comparable to what MappingJackson2JsonView or MarshallingView do by delegating to any HttpMessageWriter. So if you have a controller method that typically renders an HTML template through view resolution, it can also get rendered as JSON or XML if the client requests it. Such a method would not be annotated with @ResponseBody.

Comment From: rstoyanchev

This looks good now @sdeleuze. For the HttpMessageWriterView the compromise might use the model to pass the return type as we did previously.

Comment From: sdeleuze

Merged