Provide auto-configuration for Spring HATEOAS's new WebFlux integration

A non-exhaustive list of things to consider:

• Auto-configuration ordering
• spring-boot-starter-hateoas is currently MVC specific (it depends on spring-boot-starter-web)

[wilkinsona]

TL;DR: I think we should move this out of 2.2.x or perhaps even close this.

In addition to the ongoing discussions involving @odrotbohm and @bclozel related to media type aliasing which are not going to be resolved in the Framework 5.2/Boot 2.2 timeframe, I am now of the opinion that WebFlux-based auto-configuration will be more of a hinderance than a help to users.

Setting aside the HttpMessageConverter customization that Boot optionally performs and which is servlet-specific, the auto-configuration is reduced to a single annotation:

@EnableHypermediaSupport(type = HypermediaType.HAL)

The expanded range of media types that are supported by Spring HATEOAS mean that Boot auto-configuring HAL and only HAL is harder to justify. As soon as the user specifies @EnableHypermediaSupport (which they are now more likely to want to do), all of the auto-configuration other than the HttpMessageConverter customization backs off. WebFlux-based auto-configuration will have no equivalent HttpMessageConverter auto-configuration so in many cases it would back off entirely as the user specifies @EnableHypermediaSupport with their chosen media types.

Adding WebFlux support would also mean that the starter makes little sense any more. It currently contains three dependencies:

1. org.springframework.boot:spring-boot-starter-web
2. org.springframework.hateoas:spring-hateoas
3. org.springframework.plugin:spring-plugin-core

To allow the starter to apply to be web stacks, 1 would be removed. Furthermore 3 is no longer needed as spring-plugin-core is now a required dependency of spring-hateoas. This would leave the starter with a single module, 2, with the expectation that it’s used in combination with spring-boot-starter-web or spring-boot-starter-webflux. A single module starter doesn’t serve any purpose so it would make sense to remove it.

As I wrote the above, I realised that much of the same logic could be applied to MVC too. Once the media type aliasing discussion has been resolved (hopefully in the Framework 5.3 timeframe), it may make sense to deprecate Boot’s auto-configuration for Spring HATEOAS on the servlet-based web stack. The discussion will hopefully result in a better alternative to Boot’s HttpMessageConverter customization which will leave it in the same situation as WebFlux-based auto-configuration where it’s just auto-configuring a single annotation that will back of entirely as soon as the user tunes things. There may even be a case for deprecating the auto-configuration in 2.2. There’d be no replacement for spring.hateoas.use-hal-as-default-json-media-type but with hindsight adding that property may have been a mistake anyway. Deprecation now would help to reduce confusion about what starter to use when using HATEOAS with WebFlux with the answer being that Spring HATEOAS should be used directly without any need for a starter as it’s a single dependency.

What do you think, @odrotbohm and @gregturn? My reasoning above is based on there actually being very little for Boot to auto-configure these days. If there are, in fact, some more new features for which auto-configuration would make sense then my reasoning will no longer apply.

[gregturn]

@wilkinsona when I do this, I have managed to get things working with WebFlux…

<properties>
    <java.version>1.8</java.version>
    <spring-hateoas.version>1.0.0.BUILD-SNAPSHOT</spring-hateoas.version>
</properties>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-hateoas</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </exclusion>
    </exclusions>
</dependency>

@SpringBootApplication
@EnableHypermediaSupport(type = { HAL, HAL_FORMS })
public class HackingSpringBootApplication {

	public static void main(String[] args) {
		SpringApplication.run(HackingSpringBootApplication.class, args);
	}
}

Presumably, because this takes Spring MVC off the classpath and puts WebFlux on the classpath, Spring HATEOAS itself is able to pick the right set of beans to register itself properly.