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.

[kiwi-oss]

I ran into this with a Quarkus server today, and I'd like to comment to emphasise that this is a problem for many people.

Just like FroMage said, I spent considerable time looking for an issue in the path because I'm used to HTTP 404 meaning the resource described by the path couldn't be found. The problem was actually that I provided a date for a query parameter that expects a date-time. Then I found out that another colleague ran into the same issue a month ago by providing a query parameter of an unexpected data type.

I'm aware that the RFC says "the origin server did not find a current representation for the target resource", and one could interpret the query parameters as a specification of the resource representation, but having worked with REST services for many years, I have never seen an interpretation like that – a query parameter not conforming to the specification always resulted in HTTP 400.

[omasseau]

I agree, we should get a 400 and not a 404 if a parameter has an invalid format. 404 is way too misleading