Path annotation of different methods are interfering

[a13u]

I am using jersey 2.28 via maven and have two methods in my service class (i am using a jetty server).

@GET
@Path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc{p2:/?}{number: (([A-Za-z0-9]*)?)}")
public Response doAnything2() {
    return Response.ok("sdf").build();

}

/*with that code below the GET method does not work, if I remove it, it works*/
@POST
@Path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc/{yeah}")
public Response doAnything3() {
    return Response.ok("sdf").build();

}

With Postman I try to access
GET **P/abc/MyNumber**

If I remove the method doAnything3 I can access the GET endpoint. If I leave the method I can't access the GET endpoint (Method not found error).
Please, inform me if you have troubles reproducing the error.

[jansupol]

Uri P/abc/MyNumber matches both @Path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc/{yeah}") and @Path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc{p2:/?}{number: (([A-Za-z0-9]*)?)}"). In your case, the method with @POST is matched first and a correct method designator (i.e. @GET) is not found.

You could find a more simple example:

    @GET        
    @Path("x")
    public Response doAnything2() {
        return Response.ok("sdf").build();
    }

    @POST
    @Path("{name:[a-zA-Z][a-zA-Z_0-9]*}")
    public Response doAnything3() {
        return Response.ok("sdfa").build();
    }

In this case POST /x will not get matched.

The issue here is that you have two different @PATHs each matching the request, but the paths are not equal.

Unfortunately, you could have a resource with many resource locators, each would lead to another locator only to eventually find the method designator differs from the request type. Then, backtracking would need to be implemented to fallback to the previous resource locator and to try a different path.

For various performance reasons, it was decided the backtracking is not to be implemented and your example is (not) working as designed.

[a13u]

So even if the method (get,Post) is different, the Path Matches? Von meinem iPhone gesendet

…

Am 13.05.2019 um 22:46 schrieb jansupol ***@***.***>: Uri P/abc/MyNumber matches both @path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc/{yeah}") and @path("{Prefix}{p:/?}{id: ((\\d+)?)}/abc{p2:/?}{number: (([A-Za-z0-9]*)?)}"). In your case, the method with @post is matched first and a correct method designator (i.e. @get) is not found. You could find a more simple example: @get @path("x") public Response doAnything2() { return Response.ok("sdf").build(); } @post @path("{name:[a-zA-Z][a-zA-Z_0-9]*}") public Response doAnything3() { return Response.ok("sdfa").build(); } In this case POST /x will not get matched. The issue here is that you have two different @paths each matching the request, but the paths are not equal. Unfortunately, you could have a resource with many resource locators, each would lead to another locator only to eventually find the method designator differs from the request type. Then, backtracking would need to be implemented to fallback to the previous resource locator and to try a different path. For various performance reasons, it was decided the backtracking is not to be implemented and your example is (not) working as designed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jansupol]

I am starting to think the way it was designed is not completely correct. The method selection is described by JAX-RS Spec. Section 3.7. In Step 2, both methods should be taken to Step 3, where the method with the wrong method designator should be removed.

[a13u]

I agree :) Am 14.05.2019 21:52, schrieb jansupol:

…

I am starting to think the way it was designed is not completely correct. The method selection is described by JAX-RS Spec. Section 3.7. In Step 2, both methods should be taken to Step 3, where the method with the wrong method designator should be removed. -- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2]. Links: ------ [1] #4119?email_source=notifications&email_token=ACXCEMHA5WAIX3YB6EIMZU3PVMJ7RA5CNFSM4HJVQWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVMTDIA#issuecomment-492384672 [2] https://github.com/notifications/unsubscribe-auth/ACXCEMAWCDOQHCSFBLNY5YLPVMJ7RANCNFSM4HJVQWFQ

[jansupol]

This seems to work as described by the Request Matching Algorithm. Step 2.f sorts the resource methods, but since the sorting criterium is equal for both resource methods, step 2.g selects the first.

That being said, I think the algorithm allows for picking a correct resource in both your cases, but not requires to pick both. The algorithm does not allow for choosing a resource locator with an equal path (for instance for PUT), though.