Reroute incoming http request if rerouting target path exists

[HerrDerb]

For a little api versioning feature, I would like to "override" a couple of endpoint in versioned controller classes (Simply added a version at the begin of the base path). Those controller may only define endpoints which are relevant for this version, e.g. breaking change on the next version.
I would like to reroute an incoming request in a ContainerRequestFilter to the corresponding versioned controller if necessary. For this, I am using the version which I receive as a header, look out for a relevant versioned controller and if one found check if it contains an overridden version of the current request path. The rerouting then is done by simply adding the version to the begin of the request path. I did understand that a rerouting needs to be done in a PreMatching filter.

Now I have the problem that I could not found a reasonable way to make the matching. I see two possibilities for which I both miss a piece:

1. Preferred: Match the @Path expression of the versioned controller to the current request path -> I could not find a util or class that conveniently allows me to do that. Does this exist?
2. Resolve the original endpoint of the incoming request and use it's @Path annotation to find a matching endpoint on my versioned controllers. With this approach, I was not able to find a way to resolve an incoming request to the target endpoint (method) in a Prematching ContainerRequestFilter. Is there a util or a way to resolve an incoming request? Maybe somehow with a RequestMapper which I could not find out on how to access if possible at all.

Is it possible to resolve my problem with on of the both described ways?

Example

If have this default controller

@Path("/api")
class ItemController  {

    @GET
    @Path("/items/")
    public List<Items> getItems() {
        return getItems();
    }

    @Post
    @Path("/items/")
    public void createItem(Item item) {
         createItem(item);
    }
}

and this versioned controller which handles request up to 10.0 which only "overrides" the GET endpoint

@Path("/v10.0/api")
class V10ItemController implements VersionedController {

    @Overriden
    public Version getTargetingMaxVersion() {
        return new Version(10, 0);
    }

    @GET
    @Path("/items/")
    public Response getItems() {
        return Response.ok().build();
    }
}

On an incoming request like:
Example incoming request:

GET http://localhost:8080/api/items/
Headers: {'X-APP-Version': '9.0'}

I select the matching versioned controller and want to reroute to the overridden endpoint if exists. In this case, the rerouted request would look like:

GET http://localhost:8080/v10.0/api/items/
Headers: {'X-APP-Version': '9.0'}

While selecting the versioned controller is not a problem, I have the problem (described above) to verify if the versioned controller contains an overridden endpoint for the incoming request.

[HerrDerb]

Maybe @FroMage @stuartwdouglas or @geoand might know where to look?

[HerrDerb]

I got a working version by converting the path expressions to a regex like:

    public static Pattern generateRegexFromPath(String pathAnnotation) {
        // Escape special regex characters and replace path parameters with regex patterns
        String regex = pathAnnotation.replaceAll("\\{[^/]+}", "[^/]+");
        // Add start and end anchors and ignore leading /
        regex = "^/?" + regex + "$";
        return Pattern.compile(regex);
    }

With the prematching filter I've got now, I can route a request to the versioned controller that handles a breaking changes for the incoming version.

Lets say the incoming request comes from app with version 8.0. After Version 10.2 I have a breaking change on Path /abc.
I start checking all versioned controller for Path /abc starting at version 8.0, I will get a match with 10.2 and simply add v10.2 to the path and reroute.

This way the client does not need to know about and the the latest code neither. I only have to define a versioned controller with an "override" of the endpoint that has breaking changes for the next version.

[FroMage]

OK, great :)

[HerrDerb]

@FroMage so just to be sure 🙂 there is no way, within the scope of a pre matching filter, on how I could use any existing mechanism in quarkus to avoid the custom regex matching?

[FroMage]

Not that I know of, no.

[HerrDerb]

@FroMage Thanks for you time and inputs 👍🙂

[HerrDerb]

Found a working solution in the scope of a prematching filter