Java 如何以编程方式确定JAX-RS资源路径？

假设我有一组JAX-RS定位器和子定位器，如下所示：

@Path("/users")
public class UserListResource {
   @Path("/{id}")
   public UserResource getCustomer(@PathParam("id") int id) {
      // Find and return user object
   }
}

public class UserResource {
  @GET
  public String get() {...}
}

例如，ID为

5

的

UserResource

对象将具有路径

“/users/5”

。在我的系统中，我有几种不同的资源

现在的问题是：服务器如何计算给定资源的路径？我可以通过一些JAX-RSAPI以编程的方式实现这一点，还是必须实现使用反射的代码？（我知道后一种方法，但更喜欢另一种方法。）

• 当我需要知道路径时，我根本没有请求对象。例如，我有一个计时器，它执行一些后台处理，然后更改域模型中的一些实体，然后通知所有客户端有关更改的实体（包括它们的路径）
• 我知道，在请求的范围内，我可以注入一个提供此功能的

  UriInfo

  对象，但我需要提前知道路径（通知客户端不一定通过JAX-RS资源发生的更改）
• 我不想在其他地方重复路径信息，也不想为每个资源类型（在本例中为

  “/users”

  和

  “/{id}”

  ）设置一组路径片段常量

---

我理解您的问题，您希望在请求进入时，但在它到达您的资源之前，知道路径；您是否愿意使用Servlet过滤器

---

JAX-RS特定过滤器仅在2.0中受支持。在我阅读您的问题时，您需要构建一个只知道资源类和

id

参数的URI

可以使用

UriBuilder

类完成此操作，如中所示：

UriBuilder builder=UriBuilder.fromResource(UserListResource.class);
URI uri=builder.path(UserListResource.class,"getCustomer").build(5);

---

它在引擎盖下使用反射，因此重构不是那么容易，但目前它是所有可用的。

总体而言，请注意，应用程序的体系结构听起来有些奇怪。这很难指指点点，但是你问的问题的模式是关于你如何处理这件事的一些危险信号。请注意，如果您正试图为应用程序创建RESTful API，您可能需要停止，请后退几步，重新考虑您正在尝试做什么

对于你明确的问题

现在的问题是：服务器如何计算给定资源的路径？我可以通过一些JAX-RSAPI以编程的方式实现这一点，还是必须实现使用反射的代码？（我知道后一种方法，但更喜欢另一种方法。）

服务器知道路径，因为路径总是由用户提供的，用于在组成应用程序的资源类集合中导航。如果特定调用需要

UriInfo

实例，则应将其作为特定调用的一部分注入：

@GET
public String get(@Context UriInfo info) {...}

在构建过程中，最好传入外部上下文所需的任何信息（例如，资源的ID是什么）。您可以再次从URL（可从

UriInfo

获取）中重新分析它，但这可能是错误的方法

否则，如果你正在做更复杂的事情，那么你需要在你的问题上更加具体

• 当我需要知道路径时，我根本没有请求对象。例如，我有一个计时器，它执行一些后台处理，然后更改域模型中的一些实体，然后通知所有客户端有关更改的实体（包括它们的路径）
• 我知道，在请求的范围内，我可以注入一个提供此功能的

  UriInfo

  对象，但我需要提前知道路径（通知客户端不一定通过JAX-RS资源发生的更改）

你将如何通知客户？通常没有将消息从服务器推送到客户机的机制，客户机通常通过防火墙，因此无法直接承载服务

从理论上讲，您可以将每个资源与其自己的RSS提要相关联（明确地，通过URL），客户机可以根据自己的选择收听RSS提要。你不能强迫客户倾听，但你可以给他们这样做的选择。如果你走这条路线，你不需要知道

UriInfo

“提前”，因为位置信息将出现在关键时刻（即，在资源创建时），之后你只是指你可以控制的东西

但这只是一种方法，它增加了很多复杂性；只有当它对您的应用程序至关重要时，您才会这样做。经常让客户进行民意调查通常更简单。（请注意，某些类型的修改本质上是非常具有破坏性的；尤其是更改ID或删除资源。不要期望事情能够顺利地处理这些。）

• 我不想在其他地方重复路径信息，也不想为每个资源类型（在本例中为“

  /users

  ”和“

  /{id}

  ”）设置一组路径片段常量

---

很难。在多个位置重复信息是一种常见的做法，前提是您从一个源一致地绘制信息。它实际上没有什么问题。

记录在案：在我发布了这个问题之后，我对我们的架构进行了更多的思考，并得出结论，发送URL没有我想象的那么有用。无论如何，应用程序必须了解有关应用程序结构的一些详细信息：

• 继续上面的例子：即使客户端不知道单个用户的URL模式，它也必须假设有一个用户列表并知道其URL；它还具有硬编码的知识，可以显示什么对话框来编辑用户等

总之，试图告诉客户机（大多数）它需要的URL是不值得的。相反，我们决定使用一个自定义API定义文件，其中包含关于t的数据