This draft PR brings the new hints API based on Map<String, Object>, a reactive port of RequestBodyAdvice and ResponseBodyAdvice and a concrete use case with the JsonView support for both request and response body.

Thanks in advance for your feedback @rstoyanchev, @bclozel, @poutsma !

Comment From: poutsma

I mainly focussed on the first two commits in this PR, and they look good. The only thing I would change is the name hints for the map parameter, as it does not work really for me. properties perhaps, attributes or event decoder/encoderAttributes?

Comment From: sdeleuze

Thanks.

I agree that hints is maybe not the best name. Whatever name we chose, maybe that's better to use decodingXxx / encodingXxx because these information are tied to each encode() / decode() invocation.

So why not decodingAttribute / encodingAttribute, or maybe decodingContext / encodingContext ...

Comment From: bclozel

Looking good! About renaming hints into something else — I'd like to clarify something first.

Those "hints" can change for each encode/decode call, depending on which part of the application calls it? To me "attributes" sounds like it's part of the encoder state, "context" something that can be passed around and mutated by any participant, and "parameters"... like method parameters.

Which one is the closest to the actual meaning here?

Comment From: rstoyanchev

@poutsma why does "hints" not work? They are indeed additional input or ques (basically hints) to aid with the encoding or decoding. I realize this is now quite subjective but for me properties and also attributes carry additional connotations (Encoder/Decoder Java properties, or context state for attributes as Brian alluded to) that make them less than ideal.

Beyond the naming, I think the first two commits make perfect sense as part of this PR. The additional two commits should have a separate PR, ticket, and merit a separate discussion. After all SPR-14557 is merely about refactoring how hints are passed in. I will add more of the general concern I have around the body advice under SPR-14557.

As for the actual refactoring, looks good overall but do we really need the default methods on Encoder, Decoder, HttpMessageReader, and HttpMessageWriter? The number of methods in each of these contracts have now doubled making them much less readable. I can appreciate the trade-off with convenience on highly visible API types but these are internal SPI types primarily used by the framework, or potentially other frameworks. It really isn't a big deal to pass hints always even as an empty map. It happens in very few places.

I would also question if we need the methods exposing the supported hints on those same contracts. The constants on individual encoders/decoders communicate the hints well and I doubt there is a need for programmatic checks, or at least I would wait for specific use cases before adding them.

Comment From: poutsma

@poutsma why does "hints" not work?

I have no problem with hints, but I just thought "attributes" might work better. We use attributes in many other places which seem similar: model attributes, request attributes, and so on.

Comment From: sdeleuze

As discussed previously, I have polished and merge the 2 first commits (see https://github.com/spring-projects/spring-framework/commit/b91867cf45d07be14e6c8f5ae5437e049552d19d and https://github.com/spring-projects/spring-framework/commit/aaba53f76a6c59166eda1215c8524db33173648c). The 2 next commits will be discussed in SPR-14693 and will lead to the creation of a new PR.