When Jersey cannot map a query parameter, it fails with 404, why so?

Question

I'm not a Jersey guru but I read that Jersey cannot resolve Java methods based on query params, but it looks sometimes it does, here is my example.

This is the server code:

@GET
@Path("/services")
public String getAll(
        @QueryParam("limit") Integer limit,
        @QueryParam("offset") Integer offset){
        return "1 2 3";
}

And this is the client code:

ClientResponse response = webResource
        .path("services")
        .queryParam("limit", "ab")
        .get(ClientResponse.class);
logger.info(response.toString());
assertEquals(response.getStatus(), 200);

It looks like Jersey doesn't like "ab" and isn't able to map the query param so it returns 404, however if limit = "1", i can hit the right method.

Is Jersey right to return 404 in this case? I know i could broaden the interface using String rather than Integer to override all the treatment for any feasible syntax error. Can I configure Jersey to do this on my behalf?

I'm using server: Grizzly/1.9.18, with Jersey 1.11

Armory

Answer 1

Currently this is not possible in Jersey. Maybe we could come up with a feature to make this more friendly. How about something like @ErrorParam annotation you can attach to a parameter. If such parameter is present and some QueryParam conversion fails, the query param would be populated with the default value and the real string value of the param in error would be added to the name-value map passed in the param annotated with @ErrorParam?

@GET
@Path("/services")
public String getAll(
        @QueryParam("limit") Integer limit,
        @QueryParam("offset") Integer offset,
        @ErrorParam MultivaluedMap<String, String> typeErrors) {

    if (!typeErrors.isEmpty()) {
        // do something
    }

    return "1 2 3";
}

I filed an RFE here: https://github.com/eclipse-ee4j/jersey/issues/1535 (old, dead URL: http://java.net/jira/browse/JERSEY-1263 )

Please comment if you have an opinion.

Recreation

Answer 2

Required by specification

To add some background to Martin Matula's answer:

Yes, if the value for a request parameter cannot be parsed, Jersey will return HTTP 404 (and not HTTP 400, as might be expected). This is for both path parameters (@PathParam) and query parameters (@QueryParam). This happens not only in Jersey, it is mandated by the JAX-RS specification (emphasis mine):

A WebApplicationException thrown during construction of field or property values using any of the 5 steps listed above is processed directly as described in Exceptions. Other exceptions thrown during construction of field or property values using any of the 5 steps listed above are treated as client errors: 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; [...]

Jakarta RESTful Web Services V3.1.0: 3.2. Fields and Bean Properties

Rationale

While this may be somewhat surprising, Paul Sandoz (then at Sun) gave a rationale on the Jersey mailing list in 2009:

JAX-RS specifies a 404 should be returned:

[...]

The EG opted for a 404 when extracting parameters from URI because strictly speaking if a String cannot be converted to say Integer then it is a matching error with the URI.

Message from Paul Sandoz to jersey.java.net from 2009-08-14

So the EG (Expert Group) decided that a wrong parameter is just a special case of a wrong URI, and therefore HTTP 404 is appropriate. Debatable, but not totally unreasonable.

Caoutchouc

I totally see how it works for pathParams, but whoever decided to apply the same logic to QueryParams, should be singled out and subjected to a life (or afterlife) of shame and despair. – Gravante

Answer 3

in jersey's document it said about @QueryParam : "will be assigned to the step method parameter. If the "step" value cannot be parsed as a 32 bit signed integer then a HTTP 404 (Not Found) response is returned"

Neonatal