Provide a mechanism to serve hypermedia responses to requests that accept application/json

[wilkinsona]

In Spring Boot 1.2 (I think) we added support for serving HAL in response to requests that accept application/json. This was originally mentioned in this comment but I think it ought to be tracked as a separate issue.

The way that we achieve the behaviour described above has changed a bit over time. The current implementation relies on the mutability of TypeConstrainedMappingJackson2HttpMessageConverter to add application/json to its supported media types. We need to be able to do something similar for HATEOAS on top of WebFlux and I don't think it's possible without resorting to reflection at the moment.

Taking a step back, perhaps it would be better to revisit the approach that we took for MVC at the same time and for Spring HATEOAS to provide a first-class configuration setting for this?

This is a similar issue to #1073 but is about allowing requests for application/json to receive a HAL (or other format) response.

[gregturn]

On this commit I coded support where a given media type could also register for application/json.

674ea29

It feels kind of clunky. Not sure what a proper API would be that says “when asking for plain JSON, serve HAL”. Maybe it is this?

Or perhaps this but just for HAL.

[gregturn]

We have a dedicated HalConfiguration bean to alter rendering of HAL. Perhaps that could be the place to “register” additional media types for the same serializer.

[gregturn]

In fact putting this setting inside HalConfiguration sounds more appealing than encoding such decision into the media type handler itself. It would also grant Boot the ability to inject this through any means desired.

[wilkinsona]

Thanks for taking a look, Greg. FWIW, 674ea29 doesn't look too clunky to me. One thing I did notice is that I think the default is now that HAL would be served in response to a request that accepts application/json. I wouldn't change the default in HATEOAS, just provide an option to enable that behaviour.

It would also grant Boot the ability to inject this through any means desired.

That's what we really need from a Boot perspective. If you have time to code something up in that direction then I'd be happy to take a look at how it would integrate into Boot. It may allow us to get spring-projects/spring-boot#16020 into Boot 2.2.

[gregturn]

wdyt @wilkinsona?

10% of this is the code to register extra mediatypes. 90% is the copying of test cases for HAL and HAL-FORMS against both WebFlux and WebMVC.

[odrotbohm]

I don't think this should be solved on the HMC level but rather in content negotiation with the user explicitly defining which media type she want's to see for a request for application/json. The HMC defines which format it can produce and shouldn't have to deal with "Well, I want to say application/json but actually mean application/prs.foobar+json". That's content negotiation and the HMC are means consulted in the decision not the abstraction driving it.

Content negotiation for requests is done in MVC. If media type aliasing is supposed to be supported, it should live there. application/json is just one example, custom, user defined media types are another. Of course we can wire all of these things down into the HMC / Encoder implementations but there's just no need for that kind of knowledge so deep down the call stack.

The approach is also at odds with us allowing to register custom media type implementations that would have to know about this, use a dedicated base class so that Boot can tweak their setups as well. All of this has much bigger impact and complexity than MVC aliasing the media type in its content negotiation process.