当 Jersey 无法映射查询参数时，会失败并返回 404，为什么会这样？

Question

我不是 Jersey 专家，但我读到 Jersey 无法根据查询参数解析 Java 方法，但有时看起来确实如此，这是我的示例。

这是服务器代码：

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

这是客户端代码：

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

看起来 Jersey 不喜欢“ab”并且无法映射查询参数，因此它返回 404，但是如果 limit =“1”，我可以使用正确的方法。

这种情况下Jersey返回404正确吗？我知道我可以使用 String 而不是 Integer 来扩展接口，以覆盖对任何可行语法错误的所有处理。我可以配置 Jersey 来代表我执行此操作吗？

我正在使用服务器：Grizzly/1.9.18，带有 Jersey 1.11

Answer 1

目前这在泽西岛是不可能的。也许我们可以想出一个功能来使其更加友好。可以将 @ErrorParam 注释之类的东西附加到参数上怎么样？如果存在此类参数并且某些 QueryParam 转换失败，则查询参数将使用默认值填充，并且错误参数的真实字符串值将添加到用 @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";
}

我在这里提交了 RFE：https://github.com/eclipse-ee4j/jersey/issues/1535（旧的、死的 URL：http://java.net/jira/browse/JERSEY-1263）

如有意见请评论。

Answer 2

在 jersey 的 document 中，它谈到了 @QueryParam ：“将被分配给步骤方法参数。如果“步骤”值无法解析为 32 位有符号整数，则返回 HTTP 404（未找到）响应”

Answer 3

为 Martin Matula 的答案添加一些背景：

是的，如果无法解析请求参数的值，Jersey 将返回 HTTP 404（而不是预期的 HTTP 400）。这适用于路径参数 (

@PathParam

) 和查询参数 (

@QueryParam

)。这种情况不仅发生在泽西岛，而且是 JAX-RS 规范强制要求的（重点是我的）：

在构造字段或字段期间抛出 WebApplicationException 使用上面列出的 5 个步骤中的任何一个来处理属性值 直接按照异常中的描述。期间抛出的其他异常 使用以下 5 个步骤中的任意一个构建字段或属性值 上面列出的被视为客户端错误： 如果字段或属性是 用 @MatrixParam、@QueryParam 或 @PathParam 注释，然后 实现必须生成 NotFoundException 的实例（404 status) 包装抛出的异常并且没有实体； [...]

雅加达 RESTful Web 服务 V3.1.0：3.2。字段和 Bean 属性

虽然这可能有些令人惊讶，但 Paul Sandoz（当时在 Sun）在 2009 年的 Jersey 邮件列表中给出了一个理由：

JAX-RS 指定应返回 404：

[...]

EG 在从 URI 中提取参数时选择了 404，因为 严格来说，如果字符串无法转换为整数，则 这是与 URI 的匹配错误。

Paul Sandoz 于 2009 年 8 月 14 日发给 jersey.java.net 的消息

因此 EG（专家组）认为错误的参数只是错误 URI 的特例，因此 HTTP 404 是合适的。有争议，但并非完全没有道理。