Nested entities that contain a reference to an aggregate root get a link to that attached to their representation. Previously, the creation of those links assumed that the reference is a materialized instance of the remote aggregate. That's now altered to be able to deal with associations, use identifiers directly or materialize to an intermediate aggregate instance to potentially use a custom lookup.
Finally remove the dependency to Spring WebMVC from Spring Data REST's core module. Removed previously deprecated methods and update test configuration applying customizations.
Related tickets: DATAREST-1543.
Removed Java8PluginRegistry not in use anymore anyway. Same for RepositoryRestConfigurerAdapter. Deprecated legacy ResourceMappingUtils and its client code exposed in RepositoryRestConfiguration as it's also not considered anymore.
We now use Spring's path prefix capabilities to apply Spring Data REST's base path to its mappings. This was previously implemented by tweaking the matching conditions.
We now also pick up Spring 5.3's PathPatternParser and apply that to the custom HandlerMapping implementations we register.
Moved DelegatingHandlerMapping into the configuration package to be able to keep it around in package scope.
Deprecated RepositoryRestConfiguration.getBaseUri() as we have only supported paths for quite a while now. Moved all client code to ….getBasePath() instead.
We now use the current request's URI as base link for all links created for a collection resource. This especially has effect in the creation of pagination links as we now carry potentially applied critierias (induced by our Querydsl based filtering support) forward to the navigation links generated.
The usage of text/uri-list as media type was entirely broken and not even advertised in the reference docs anymore. It's now again supported for both to-one and to-many associations via Collections. Maps are rejected as they cannot be rendered as list of URIs correctly. Updated reference documentation accordingly.
Added a custom MapModel implementation of RepresentationModel as apparently using Maps with EntityModel does not unwrap the content properly due to [0].
[0] https://github.com/FasterXML/jackson-databind/issues/171
