Support `Predicate<RequestPath>>` in path API version resolver

[siom79]

When using API Versioning together with springdoc with swagger-ui enabled and path segments, the URL to load the openapi spec changes from /v3/api-docs (default) to /v3/v1/api-docs (when using ApiVersionConfigurer.usePathSegment(1)). But the swagger-ui still uses the default URL /v3/api-docs to load the openapi spec and fails.
My current workaround is to write a custom version resolver that extends from PathApiVersionResolver to exclude the mentioned URLs from API versioning (as the openapi document anyhow lists the different versions).
So instead of having to write a custom version resolver, it would be great to have an excludePaths() method on the ApiVersionConfigurer that does exactly that:

@Configuration
public class WebConfiguration implements WebMvcConfigurer {

  public static final String DEFAULT_VERSION = "v1";

  @Override
  public void configureApiVersioning(ApiVersionConfigurer configurer) {
    configurer
        .usePathSegment(1)
        .setDefaultVersion(DEFAULT_VERSION)
        .addSupportedVersions(DEFAULT_VERSION, "v2")
        .excludesPaths("/v3/api-docs*/**","/swagger-ui/**"); // proposed method
  }

What do you think?

[rstoyanchev]

The problem is unique to path-based versions for which there is no notion of an absent version. No way to tell if a URL is badly formed, or is not meant to have a version.

I think the solution and configuration should also be specific to path versioning, therefore should not be a top level option, but rather a variant of usePathSegment with additional input, which will be passed specifically to the PathApiVersionResolver in any case.

A list of exclude path patterns is an option, but it would be simpler to exclude by path prefix (startsWith), e.g. List.of("/v3/api-docs", "/swagger-ui").

Another option is Predicate<RequestPath> to make a decision if the path has a version or not. You could then check by exclusion by inspecting specific path segments, or by inclusion by checking the path starts with "/v3/v" for example, or a combination, e.g. segment 0 is "v1" and segment 1 does not start with "api-docs".

[siom79]

Yes, you could create the feature as a variant of usePathSegment(). But I think there might be use cases where one likes to exclude certain paths from versioning when using request headers, too.

Providing an instance of Predicate<RequestPath> is an good idea. It is a way more flexible than having strings and wildcards.

If you agree on that solution, I can contribute a PR.

[rstoyanchev]

Making the path version resolver more flexible with a Predicate<RequestPath> is a good idea on its own, so feel free to send a PR for that.

Other resolvers can already detect the absence of a version, and then default version handling applies. If this is all we are talking about, then all other resolvers are already capable of that. The path resolver is the only one that can't, but this change would bring it on par, and its contract would also become nullable like the rest.