我真的很困惑。我已经尝试使用带有 tomcat 的 Jax-rs 并使用所有注释,我能够使用 url
调用我的服务。因此,如果没有 Jax-rs,我可以简单地拥有一个 servlet 并调用我的服务。同样,正如我所尝试的那样,有带有 Jersey 的 jax-rs(因为我研究了它的 JAX-RS
实现)并且在 web.xml 中有以下内容。
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd" >
<web-app>
<display-name>OutputUi</display-name>
<servlet>
<servlet-name>jersey-serlvet</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>org.xxx.carbon.servlet</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-serlvet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
然后我有与 JAX-RS 相同的注释,在 GET 上我可以使用正确的 URL 调用我的服务。
我的问题是,为什么 Jersey 使用 servlet? JAX-RS
不使用 servlet 吗?为什么要使用 JAX-RS
,而我们可以只使用 Servlet。
最佳答案
JAX-RS 指定了一个围绕 Servlets 的部署模型[1]。为什么,因为在 Java 世界中,Web 应用程序就是这样运行的。请求进入 Servlet 容器(如 Tomcat 或完整 Java EE 服务器中的容器),容器将请求传递给 Servlet 应用程序,应用程序处理请求并将响应吐回容器,容器将其发送给客户。 Spring MVC 是一个基于 Servlet 的框架(主要 Servlet 是 DispatcherServlet
)。 JSF 是一个基于 Servlet 的框架(主要 Servlet 是 FacesServlet
)。 JAX-RS 也是围绕 Servlet 构建的(主要 Servlet 是特定于实现的;在 Jersey 的情况下,它是 ServletContainer
)。
请求进入 Tomcat,它查找 servlet 映射,它发现 ServletContainer
与请求 URL 匹配,它将请求包装在 HttpServletRequest
中并将其发送到 Jersey Servlet。现在 Jersey 可以随心所欲地处理它,这是一大堆处理;例如处理请求以匹配您的方法[2]、反序列化实体主体,以及一大堆其他使所有魔法成为可能的东西。完成处理后,它将响应发送回容器。
why jersey using a servlet?
我认为上面已经说得很清楚了。
JAX-RS not using a servlet?
不太确定我是否真的理解您的要求,但 JAX-RS 指定了其他部署模型,但 Servlet 环境是唯一具有任何特定要求详细信息的环境。其他部署选项(例如在 SE 环境中)将特定于实现[1]。
Why using JAX-RS, while we can use a just Servlet
您基本上是在问,“当我可以实现自己的 REST 框架时,我为什么要使用 JAX-RS?”。通常,当有可用的框架时,就使用它。如果您觉得自己可以做得更好,那就去做吧。
[1] - 参见 2.3 Publication
[2] - 请参阅 3.7 Matching Requests to Resource Methods
更新
因此,部分 OP 的部分困惑是,他正在学习的教程没有在 web.xml 文件中指定 Servlet,这让 OP 认为“vanilla JAX-RS” (不存在)正在被使用,而不是实现。
JAX-RS 只是一个规范,没有实现就无法运行。是的,有一个 javax.ws.rx-api.jar
或一个 javaee-api.jar
具有要编译 一个 JAX-RS 应用程序,但此 jar 中没有实际的“引擎”。实际的 JAX-RS“引擎”在特定的实现 jar 中。
我没有看过完整的教程,但我假设它使用了上述 jar 之一,这导致 OP 认为没有使用 JAX-RS 实现。但实际上,使用的 Java EE 服务器(即 Glassfish)在内部具有实现。对于 Glassfish,它是 Jersey。
另一个混淆点可能出现在应用程序配置中。不像在 OP 的帖子中那样使用 web.xml,而是使用了一个 Application
子类。有点像
@ApplicationPath("/rest")
public class AppConfig extends Application {
...
}
JAX-RS 规范指出,当带有注解的此类可用时,应使用上述完全限定的类名作为 Servlet 名称创建一个 Servlet,并且 url 映射为 @ApplicationPath 中的值
。因此,无论您使用什么实现,这种行为都应该是相同的。
关于java - 与 JAX-RS 混淆,Jersey 与 JAX-RS 混淆,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29149650/