我是 Java 中使用 REST 的新手。
在检查在 java 中实现 REST 服务的应用程序时，我看到了在 javax.ws.rs 包中定义的类。
据我了解，JAX-RS 是一种规范，为了使用它，您需要一个实现，例如 Jersey。
为什么我在应用程序中看到的类是 JAX-RS 类，例如 javax.ws.rs.core.Response 类。
如前所述，这些课程不应该是泽西课程吗？
还是可以直接使用“规范类”？
我以为我会看到的所有类都是来自 Jersey API 的类，但事实并非如此。 有人可以解释何时使用规范与实现中的类吗？
【问题讨论】：
Response 类是抽象的。如果您查看正在使用它的代码，则必须有一些具体的实现。也许泽西岛正在提供该实现。
标签： java rest jax-rs specifications
javax.ws.rs.core.Response 是 JAX-RS API 的一部分，即一个规范。
它是一个抽象类，因此不能实例化。
Jersey 实现 Response in com.sun.jersey.core.spi.factory.ResponseImpl。实际名称无关紧要，因为您应该使用 ResponseBuilder JAX-RS API 实例化 Response。
例如：
Response res = Response.ok().build();
这将在内部查找一个实现并实例化它。
（如果您只包含 JAX-RS API，该调用将在运行时失败）
【讨论】：
<servlet> 中指定了一个实现。我认为这就是“内部查找实现”的工作原理？这对我来说是个谜，我从未见过类本身中提到的实现。
RuntimeDelegate.findDelegate() 内部，这是一个简单的类路径搜索。只要实现在类路径上，它就可以工作。
规范确实只是定义了任何 JAX-RS 实现（例如 Jersey）应该实现的 API。
这个 API 主要包括接口（所以没有实现）和注解，API 的用户可以用它们来装饰他们的类，并且实现应该相应地处理和处理。
如您所见，API 还定义了一些抽象或具体的类。这主要用于 API 定义接口方法所期望的一些数据结构的地方。也可能是规范强制执行的一些最小 API 级别逻辑。他们被故意隔离到这个javax.ws.rs.core 包中。
在您的情况下，Response 是一个抽象类。在这种特定情况下，真正的原因可能仅仅是因为在 Java 8 之前，您不允许在接口中使用 static 方法。正如你所看到的，它有很多static 实用方法。它还提供了一个具体的实例方法getHeaders()，设计人员认为它可能总是相同的（在Java 8 之后，这可能是一个default 接口方法）。
有一个 few other classes 可能出于类似的原因而存在，作为 API 的支持类。
【讨论】：
规范背后的主要思想是允许使用可以在任何兼容实现上运行的“标准”API 开发应用程序，重点是无论您使用 Jersey，JAX-RS 应用程序都应该以最小的更改工作, Reasteasy, 或其他实现；这使它们便于携带。
这不是特定于JAX-RS：对于JAX-WS、Java EE、JDBC 和许多其他规范也可以这样说。可以使用特定于实现的类（一些实现甚至为此提供文档），但可移植的 JAX-RS 代码使用标准 API。
【讨论】：