Breaking change in semantics of `WebMvcLinkBuilder.linkTo(Class<?>, Method, Object…)` in 1.3.4

[EarthCitizen]

When upgrading from Spring Boot 2.5.4 to 2.5.6, the version of Spring HATEOAS pulled in changes from 1.3.3 to 1.3.5. This broke our code using the WebMvcLinkBuilder method:

public static WebMvcLinkBuilder linkTo(Class<?> controller, Method method, Object... parameters) {

As can be seen below, the changes introduced in 1.3.4 are not backwards compatible with 1.3.3. The 1.3.3 version of the method only expects the URL template variables to be given, whereas starting from 1.3.4 is expecting all parameters from the actual controller method.

1.3.3:

	public static WebMvcLinkBuilder linkTo(Class<?> controller, Method method, Object... parameters) {

		Assert.notNull(controller, "Controller type must not be null!");
		Assert.notNull(method, "Method must not be null!");

		String mapping = SpringAffordanceBuilder.DISCOVERER.getMapping(controller, method);
		UriTemplate template = UriTemplateFactory.templateFor(mapping);
		URI uri = template.expand(parameters);

		return new WebMvcLinkBuilder(UriComponentsBuilderFactory.getComponents()).slash(uri);
	}

1.3.4:

	public static WebMvcLinkBuilder linkTo(Class<?> controller, Method method, Object... parameters) {

		Assert.notNull(controller, "Controller type must not be null!");
		Assert.notNull(method, "Method must not be null!");
		Assert.notNull(parameters, "Parameters must not be null!");

		return linkTo(DummyInvocationUtils.getLastInvocationAware(controller, method, parameters));
	}

1.3.5:

	public static WebMvcLinkBuilder linkTo(Class<?> controller, Method method, Object... parameters) {

		Assert.notNull(controller, "Controller type must not be null!");
		Assert.notNull(method, "Method must not be null!");
		Assert.notNull(parameters, "Parameters must not be null!");

		int expected = method.getParameterTypes().length;
		int given = parameters.length;

		Assert.isTrue(expected == given,
				() -> String.format("Incorrect number of parameter values given. Expected %s, got %s!", expected, given));

		return linkTo(DummyInvocationUtils.getLastInvocationAware(controller, method, parameters));
	}

[odrotbohm]

Can you please elaborate on your use case a bit? The changes were introduced to fix #1588 actually make sure that missing request parameters lead to template variables to be rendered. The step to 1.3.5 was introduced to avoid mismatches between the needed parameters and the ones provided (in the context of #1652).

As the code in 1.3.3 expands the URI template into a URI I don't quite understand how that would work, without providing all parameters to be bound to the mapped template in the first place as a template.expand(…) throws an IllegalArgumentException if invoked with an insufficient number of values needed for expansion.

[imaykay]

I don't want to hijack this issue, but as we ran into the same error, I quickly wanted to share our use case. It might be broken down to a simple controller method as this:

@PutMapping("/users/{userid}/orders")
public EntityModel<Order> createOrderForUser( //
        HttpServletRequest request, //
        @PathVariable("userid") String userId) {
    ...
}

So if the controller method takes additional parameters beside the url variables, the assertion fails. Maybe the method parameter list needs to filtered for link relevant params first?

[EarthCitizen]

@odrotbohm It is not so much of a use case as it is just pointing out that this broke backwards compatibility, in case there was not awareness that this had happened. Basically, we were only passing parameters that would expand the template parameters, then we we upgraded from 1.3.3 to 1.3.5, and our uses of WebMvcLinkBuilder linkTo(Class<?> controller, Method method, Object... parameters) were broken.

What was nice bout the 1.3.3 version was that it was only necessary to pass in what would expand the placeholders. If there are many parameters on the controller method that are not relevant to generating the URL path, it can be tedious to pass all those in, and an additional headache if these get refactored often. This can be somewhat error prone, depending on the number of controller method parameters.