java - 我应该在 JAX-RS 中使用@QueryParam 还是@BeanParam？

Question

我正在考虑处理查询/请求参数的两个选项:

1. 将各个参数映射到相应的方法参数:

@GET
public String blah(@QueryParam("testParam") String testParam) {

}

1. 将所有参数映射到 Java bean 的属性:

@GET
public String blah(@BeanParam RequestParamBean bean) {

}

第二个选项似乎更有吸引力，因为它允许输入查询参数的验证逻辑被移动并从 blah 方法中解耦，该方法的核心职责应该是处理并将验证委托(delegate)给 validator 应该高度解耦(还有 SOLID 原则，对吧？)。

但是，我看到的大多数示例(事实上，我正在处理的现有项目)仅使用第一个选项。我想知道第二个选项是否没有被广泛使用是否有任何原因？有什么陷阱吗？这是反模式吗？这是否违反任何最佳实践？

Answer 1

JAX-RS 2.0 中引入了 @BeanParam 注释作为参数聚合器(这意味着它不能在 JAX-RS 1.0 中使用)。

---

@BeanParam 注释背后的想法是有一个 Java 类来聚合用 @XxxParam 注释注释的参数。以下 @XxxParam 注释可用于注释参数聚合器类的字段:

• @CookieParam
• @FormParam
• @HeaderParam
• @MatrixParam
• @PathParam
• @QueryParam

除了使用 @XxxParam 注释的字段，参数聚合器类还可以有使用 @Context 注释的字段。对于可以使用 @Context 注释注入(inject)的类型列表， check this answer 。

---

我相信这只是开发人员的便利和偏好问题。在许多情况下，不需要一个类来聚合参数。在方法参数中使用@XxxParam 注释非常方便。

但是当你需要在不同的方法中重用参数或者方法有很多参数用@XxxParam注解时，去@BeanParam方法。

---

在您的问题中，您提到了 SOLID principle 。但不要忘记 KISS principle :)

从方法参数中的 @XxxParam 注释开始，不要过度使用 @BeanParam 注释来尝试解决您没有的问题。如果需要，您始终可以重构代码以创建参数聚合器类。