TCK challenge: return Bad Request instead of Not Found for invalid Path/Query/Matrix parameters

[FroMage]

The spec says this:

3.2 Fields and Bean Properties

[…] if the field or property is annotated with @MatrixParam, @QueryParam or @PathParam then an implementation MUST generate an instance of NotFoundException (404 status) that wraps the thrown exception and no entity; if the field or property is annotated with @HeaderParam or @CookieParam then an implementation MUST generate an instance of BadRequestException (400 status) that wraps the thrown exception and no entity. […]

3.3.2. Parameters

[…] Exceptions thrown during construction of @FormParam annotated parameter values are treated the same as if the parameter were annotated with @HeaderParam. […]

This leads to a lot of confused users wondering why they get a Not Found when in fact someone sent a Date query or path parameter using an invalid time format, or any number of such trivial integration mistakes to make.

Returning a Bad Request rather than a Not Found would have made their lives much easier because that is the obvious thing to point to the actual error.

On the other hand, returning a Not Found invariably leads most users on a chase to find why their endpoints are not being found, suspecting some problem entirely different (a server issue: “why is this resource not registered, the path is correct, though?”) to the underlying issue (a client problem).

Is there any justification to the difference between matrix/query/path and form/cookie/header for how to report malformed parameter conversion errors?

In Quarkus, we could not think of any such justification and are thinking of deviating from the spec after many reports of confused users.