Introduce `HypermediaWebClientConfigurer` with a simple API that registers hypermedia types via `WebClient.Builder`.
Deprecate `WebClientConfigurer`, leveraging the new solution.
Update reference documentation showing how to use it, with and without Spring Boot.
Create a HypermediaRestTemplateConfigurer bean registered as a Spring HATEOAS bean.
Update reference documentation to show how to use it directly and with Spring Boot via RestTemplateCustomizer.
Appears one test case exerted a false positive. Fixing it exposed a gap and how to properly configure an existing WebTestClient (which is now in the reference docs).
This commit adds String constants to IanaLinkRelations, so that IanaLinkRelations can be leveraged in places where compile time constants are required, such as Relation#itemRelation and Relation#collectionRelation.
Switched to a less complicated implementation of the interface method parameter annotation lookup by using Spring's ClassUtils.getInterfaceMethodIfPossible(…).
Simplified test cases to pure unit test on the link builder APIs. We don't need to fully execute a complete MVC/WebFlux request/response cycle to verify the link creation to pick up the parameter annotations from the interfaces.
Original pull request: #1194.
When forming links, look at a controller class's interface definitions for possible Spring Web annotations.
Related issues: spring-projects/spring-framework#15682
Original pull request: #1194.
A bit of Javadoc on the factory methods. Avoiding abbreviations in method names, shorter parameter names. More trailing whitespace removal.
Reformatting of method invocation in test cases.
Original pull request: #1192.
This commit introduces ….of(…) factory methods on all RepresentationModel types as well as Link. RepresentationModel.of(…) transparently creates a EntityModel or CollectionModel depending on the value handed into the method.
Problem has been redesigned for immutability. Extensions to the payload body are now implemented by wrapping a either an object exposing the properties to add in turn or a plain Map.
Added infrastructure configuration to make sure that Problem instances returned from controller methods (even if wrapped into a ResponseEntity<?>) cause the ContentType header to be set to application/problem+json. HyperMediaMappingInformation now allows to customize the root domain type to signal serialization support for.
Few cleanups regarding the ObjectMapper setup in test cases.
RestTemplateHateoasConfiguration is a BeanPostProcessor and previously used a direct reference to WebConverters which caused downstream dependencies to be initialized once Spring Framework looks up BeanPostProcessors. This renders all of those dependencies ineligible of being post-processed by other BeanPostProcessors in turn.
This is now fixed by using an ObjectProvider<WebConverters> from within RestTemplateHateoasConfiguration instead, so that the initialization is delayed until the processing of the first bean is triggered.
Using a custom serializer seems to break downstream projects that also register serializers for EntityModel. We're now using extra methods on EntityModel itself that do the trick as well.
The flag to control this had been directly configured on the HalHandlerInstantiator which wasn't accessible to users in the first place. Refined the setup and forwarding of the bean factory into HalHandlerInstantiator so that non-Spring-HATEOAS Jackson serializer lookups are routed through the Spring container potentially picking up prototype bean definitions.
We now keep internal methods in EntityModel that are configured using Jackson annotations so that it'd populate the content with a Map in case Map<String, Content> is defined as payload type.
We now register a custom serializer to massage EntityModel instances into dedicated types that – in case of a Map being the content of the entity model – wrap the model into a type that applies the necessary Jackson tweaks to properly unwrap a Map.
The rendering of HAL's link relations now applies Jackson's PropertyNamingStrategy if one is configured except it's a IANA link relation. This behavior can be opt out from by setting HalConfiguration.withApplyPropertyNamingStrategy(false).
LinkRelation now has a ….map(…) method allowing the post-processing of it given a Function<String, String>. By default, that's applied to all relations that are not IANA ones. HalLinkRelation applies this transformation to only the local part of the relation. Tweaked IanaLinkRelations.isIanaLinkRelation(…) to do a simple ….contains(…) check first before we stream over all values to apply a case insensitive check.
The base URI we create now consists of the requests root URI plus the context path concatenated. On actual UriComponentsBuilder creation we then simply append the path discovered from the method mapping.
Jackson can be configured to not auto-detect properties on objects to be rendered, requiring them to be explicitly annotated with @JsonProperty to be exposed. In such a configuration setup, some of our model types do not work properly as so far we have expected public properties to be included automatically.
This commit changes that to explicitly include @JsonProperty on all of the getter methods exposed.
The implementation details of WebHandler have been significantly refactored to rather work with structures that allow better cacheability by clearly separating abstractions over the statically available information from the per-invocation aspects. This results in a new HandlerMethodParameter(s) abstraction within WebHandler. BoundMethodParameter has been removed entirely. HandlerMethodParameters are create once then cached for every controller method being linked to.
DummyInvocationUtils now creates a ThreadLocal cache of the proxies created for calls to methodOn(…) as they essentially only act as basis for subsequent calls to the methods on the proxy created which in turn are expected to be handed into a linkTo(…) call which obtains the invocation right away. This avoids overhead in cases methodOn(…) is called multiple times for the same controller from a single controller.
The lookup of the LastInvocationAware was previously routed through the proxy, handled by InvocationRecordingMethodInterceptor. This resulted in a second, reflective call for every link creation. DummyInvocationUtils now provides a dedicated lookup method as it knows about the structure of the proxy it created and thus can unfold the recorded invocation more effectively.
The LinkBuilder type hierarchy now works with UriComponents and only creates a UriComponentsBuilder if it needs to modify the backing link in the first place. This avoids superfluous back and forth between UriComponents and UriComponentsBuilders that involved quite a bit of String parsing and creation.
EncodingUtils now starts from a StandardCharsets.UTF_8 to avoid repeated Charset creation.
The changes result in a ~3x performance compared to 1.0.2.RELEASE:
1.0.2.RELEASE
Benchmark Mode Cnt Score Error Units
ControllerLinkBuilderBenchmark.noLinkCreation thrpt 10 39004583,189 ± 751668,181 ops/s
ControllerLinkBuilderBenchmark.pureLinkCreation thrpt 10 43443,133 ± 783,120 ops/s
ControllerLinkBuilderBenchmark.withLinkCreation thrpt 10 60201,629 ± 1292,179 ops/s
1.1 / 1.0.3 SNAPSHOT
Benchmark Mode Cnt Score Error Units
ControllerLinkBuilderBenchmark.noLinkCreation thrpt 10 39618560,950 ± 612794,310 ops/s
ControllerLinkBuilderBenchmark.pureLinkCreation thrpt 10 121700,634 ± 1510,415 ops/s
ControllerLinkBuilderBenchmark.withLinkCreation thrpt 10 121982,085 ± 3344,206 ops/s
noLinkCreation - creates a single RepresentationModel instance but adds no links
pureLinkCreation - creates a single link pointing to a controller method
withLinkCreation - creates a single RepresentationModel instance adding a single link
We now use the API introduced in Spring Framework 5.2.2 to customize a WebClient to add hypermedia related en- and decoders without dropping customizations potentially made to the WebClient instance.
RestTemplateHateoasConfiguration depends on a shared bean WebConverters (previously WebMvcConverters). As it can safely be used in both WebFlux and WebMVC scenarios (as it only depends on types from spring-web), we now include a declaration in the shared HateoasConfiguration. This also allows us to remove the just introduced explicit declaration of a WebConverter bean in WebFluxHateoasConfiguration.
UriTemplate now uses UriBuilderFactory (DefaultUriBuilderFactory in particular) to expand templates. We inspect the given source URI string, try to decode it and configure the factory to only encode values if the decoded String is shorter than the source one as that indicates it already contains encoded characters.
The UriBuilderFactory is held as transient value as its implementations are usually not serializable in the first place. Added the necessary logic to recreate the factory instance on deserialization.
Added all expansion tests given in the original ticket as unit tests.
RestTemplateHateoasConfiguration previously referred to HypermediaWebMvcConfigurer which is turn depending on WebMvcConfigurer, a type living in spring-webmvc. The very former would still get active in WebFlux as the web stack is selected based on the presence of either DispatcherServlet or DispatcherHandler. This is now resolved by using a WebMvcConverter indrection to handle the configuration tweaks avoiding the reference to interfaces from spring-webmvc.
Introduced an ArchUnit based test that Spring HATEOAS code only depends on Spring types containing references to reactive types from either the ….reactive package or classes starting with WebFlux.
We constrained the RepresentationModel type parameter in a way that non of the RepresentationModel subclasses we provide aren't usable with it. That's now fixed by loosing that restriction to an arbitrary type.
