Regex in @Path matches only only 1 of 2 two routes specified, resulting in 404

Here is what dropwizard logs to the console in terms configured resources and their paths:

INFO  [07:07:13.741] i.d.jersey.DropwizardResourceConfig: The following paths were found for the configured resources:

    DELETE  /apps/affiliate/internal/v1/templates/ (aff.affiliate.http.internal.AffiliateURLTemplatesInternalAPIEndpoint)
    GET     /apps/affiliate/internal/v1/templates/ (aff.affiliate.http.internal.AffiliateURLTemplatesInternalAPIEndpoint)
    POST    /apps/affiliate/internal/v1/templates/ (aff.affiliate.http.internal.AffiliateURLTemplatesInternalAPIEndpoint)
    GET     /apps/affiliate/v1/generate-url (aff.affiliate.http.AffiliateEndpoint)
    GET     /apps/affiliate/v1/redirect-search-url (aff.affiliate.http.AffiliateEndpoint)
    GET     /openapi.{type:json|yaml} (io.swagger.v3.jaxrs2.integration.resources.OpenApiResource)
    GET     /{path: apps/affiliate/v1/redirect|api/affiliate/v1/redirect} (aff.affiliate.http.RedirectEndpoint)

The problem is with the last path, specified as a regular expression.

My expectation is that it should trigger for incoming requests to both /apps/affiliate/v1/redirect and /api/affiliate/v1/redirect.

However, visiting /apps/affiliate/v1/redirect results in a 404, but visiting api/affiliate/v1/redirect results in a 200. How can I get my resource to respond to either of those paths?

The code is hard to provide but this is essentially the scaffolding (fwiw, all methods work/api works, I'm just having trouble having one of the methods respond to the regex (my actual problem)).

// AffiliateURLTemplatesInternalAPIEndpoint.kt
@Path("/apps/affiliate/internal/v1/templates")
@Produces(MediaType.APPLICATION_JSON)
public class AffiliateURLTemplatesInternalAPIEndpoint() : DropwizardResource() {
    @GET
    @Path("/")
    public fun methodA()

    @POST
    @Path("/")
    public fun methodB()

    @DELETE
    @Path("/")
    public fun methodC()
}

// AffiliateEndpoint.kt
@Path("/apps/affiliate/v1")
class AffiliateEndpoint() : DropwizardResource() {
    @GET
    @Path("generate-url")
    fun methodA()

    @GET
    @Path("redirect-search-url")
    fun methodB()

// RedirectEndpoint.kt
@Path("/{path: apps/affiliate/v1/redirect|api/affiliate/v1/redirect}")
@Produces(MediaType.APPLICATION_JSON)
class RedirectEndpoint() : DropwizardResource() {
    @GET
    fun methodA()

The 404 is indeed being correctly returned.

Why? JAX-RS’ URL Matching Algorithm.

It was only after @Paul Samsotha asked me to paste my code that I finally realized the reason for the 404. 🤦

The Dropwizard/Jersey output I was relying on shows all the routes it found, but leaves out critical context about how paths have been structured in the code. Due to the way JAX-RS has implemented route matching sorting and precedence roles, code structure is essential in determining which routes will be triggered. So in this case the helpful output ended up being mostly misleading.

Read Section 3.7 - Matching Requests to Resource Methods of JAX-RS Spec 3.0 if you dare, but the answers are there.

Also, Chapter 4 of Bill Burke's RESTful Java with JAX-RS 2.0 gives great insight into route matching behavior. Unfortunately it doesn't go into clarifying an important distinction (the exact situation I got into) which is that you can't simply combine a resource and its methods paths (like the output) when applying JAX-RS url matching rules. Actually, I went through a bunch of JAX-RS write ups and none of them mentioned this actual distinction.

Instead you first try to find a match a root resource class, then look at resource methods. If you don't find a match either at the root or method level, you must return a 404.

Still, I found it to be a great resource at shining light on the spec and is much less intimidating that the spec.

Now to the actual explanation of the 404.

Jersey (which implements the JAX-RS spec), first collects all the paths associated with root resources:

/apps/affiliate/internal/v1/templates
/apps/affiliate/v1
/{path: apps/affiliate/v1/redirect|api/affiliate/v1/redirect}

It then applies its sorting and precedence logic according the spec (paraphrased from Burke's book):

> The primary key of the sort is the number of literal characters in the full URI matching pattern. The sort is in descending order.
>
> If two or more patterns rank similar in the first, then the secondary key of the sort is the number of template expressions embedded within the pattern. This sort is in descending order.
>
> Finally, if two or more patterns rank similar in the second, then the tertiary key of the sort is the number of non-default template expressions. A default template expression is one that does not define a regular expression.

When an incoming GET request to /apps/affiliate/v1/redirect arrives, both

/apps/affiliate/v1
/{path: apps/affiliate/v1/redirect|api/affiliate/v1/redirect}

match, but the first pattern takes precedence because it has the greatest number of literal characters that match (18 vs 1).

Now that a root resource is selected, it looks at root resource's methods and compiles a list of available paths/http methods that match the incoming request. A bit of an extra detail, but for pattern matching purposes at the method level, the root resource's path will be concatenated to the resource method's path.

The following patterns are available to select from:

GET /apps/affiliate/v1/generate-url
GET /apps/affiliate/v1/redirect-search-url")

Since the request was a GET to /apps/affiliate/v1/redirect neither of the above routes match. Hence my 404 :(.

It makes complete sense, but I got into this rabbit hole because my assumptions about routing rules and precedence from experience working with other routing libraries did not align with the actual JAX-RS specs. I expected the library to have a master list for each and every method available (much like the initial output from Dropwizard/Jersey) and for each request to run through sorting and precedence rules on that master list. Alas, that is not the case.