#1061 - Reenable default codecs for WebFlux configuration.

[gregturn]

Spring WebFlux now correctly handles custom codecs. This means we can stop disabling them. This change includes more test cases, verifying Spring MVC configuration for hypermedia as well, verifying both Web MVC and WebFlux are properly and consistently configured.

Probably supercedes: #1047

[gregturn]

Feedback welcome @wilkinsona.

[wilkinsona]

Thanks for the fix, @gregturn. +1 for leaving WebFlux's default codecs enabled as disabling them makes WebFlux very cumbersome to use for any endpoints that aren't using Spring HATEOAS.

I am less sure about the fallback to Jackson, even if it is now consistent across MVC and WebFlux. For a request that accepts, say, application/vnd.amundsen-uber+json, it seems wrong to respond with plain JSON that, while legal JSON, is in the wrong format for the requested media type.

I discussed this a bit with @bclozel today and he remarked that it's an interesting use case and one that Framework would like to support. It may be too late in the schedule now for Framework 5.2 and HATEOAS 1.0, but perhaps there's something that can be done without any Framework changes.

[gregturn]

If be curious what the basis is for the wild card matcher? Sounds like it may have been put in to catch a particular situation that is now actually an issue.

[wilkinsona]

I don't know why it was added originally, but I do know it's useful for any endpoint that returns an application/*+json response that doesn't require any customization of Jackson to serialise correctly. Boot's Actuator is one example.

[wilkinsona]

It occurred to me overnight that there have been number of Boot issues (spring-projects/spring-boot#2147 is a good starting point) related to this where users expected a request for application/json to return a HAL-formatted response but it did not. That expectation seems reasonable to me as application/hal+json is a form of application/json. The inverse, however, is not the case which is the problem with the fallback for which a test is added in the pull request.

[gregturn]

I think the scope of the issue is limited because I don’t think we have a lot of people asking for, say, Collection+JSON where it wasn’t registered. Which means we can mend that in the next versions.

That being said, my inclination is to remove the wildcard matcher and to instead register handlers as needed. For Boot’s Actuator, you could register one using HATEOAS’s SPI for custom media types.

And when HATEOAS is NOT on the classpath, well you’d have to register that same handler directly with Spring Framework.

This connects with #1052

[wilkinsona]

I really don't think HATEOAS should do that. While we could do something in Boot's Actuator to work around the breaking change, it would also be a breaking change for any user application with similar endpoints.

[bclozel]

I'm not sure I'm following the whole discussion, but the "application/*+json" MIME type is registered by default in Spring Framework because many applications are using a custom type for API versioning. For example:

curl -H "Accept: application/vnd.initializr.v2.1+json" https://start.spring.io

I don't think we should disable that behavior in any case.

[gregturn]

Since the discussion about handling application/**-json is moving off topic of this one, do we need to continue it elsewhere? Or consider it resolved for now?

[wilkinsona]

Let's move it elsewhere please. I don't think it can be considered resolved and something probably needs to be done before 1.0 GAs and reduces the options available to fix it.

[gregturn]

Resolved via fd70fd9.

[gregturn]

Thanks @wilkinsona @bclozel for your feedback. This issue is now resolved regarding Spring HATEOAS.

[wilkinsona]

Is there a new HATEOAS issue to discuss the problems with application/*+json handling?

[gregturn]

Frankly, I thought that was a Framework issue to discuss. ;)

[wilkinsona]

There may be some changes needed in Framework but I think changes will also, if not exclusively, be needed in Spring HATEOAS. IMO, the problem should be tracked here until a plan of attack has been devised. At that point, a Framework issue can be opened if it's needed.

[gregturn]

See #1073 for the continuation of this broader topic. Whether or not this is a Framework issue or what can be found there.