使用JAX-RS混淆了JAX-RS和Jersey

Question

我真的很困惑。 我已经尝试了一个带有tomcat的Jax-rs并使用所有注释我能够使用url调用我的服务。 所以没有Jax-rs，我可以简单地拥有一个servlet并调用我的服务。 另外正如我所尝试的那样，jones-rs with jersey（正如我已经研究过它的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调用我的服务。

我的问题是，为什么球衣使用servlet？ JAX-RS没有使用servlet？ 为什么使用JAX-RS ，而我们可以使用一个只是Servlet。

Answer 1

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。 现在泽西岛可以随心所欲，这是一个很大的处理; 比如处理请求以匹配您的方法^{[ 2 ]} ，反序列化实体主体，以及一大堆其他可以实现所有魔法的东西。 完成处理后，它会将响应发送回容器。

为什么球衣使用servlet？

我认为上面已经说清楚了。

JAX-RS没有使用servlet？

我并不确定我真的理解你所问的是什么，但JAX-RS指定了其他部署模型，但Servlet环境是唯一具有任何特定需求细节的环境。 其他部署选项（如SE环境）将是特定于实现的^{[ 1 ]} 。

为什么使用JAX-RS，而我们可以使用一个只是Servlet

你基本上会问，“当我可以实现自己的REST框架时，为什么要使用JAX-RS？”。 通常，当有可用的框架时，请使用它。 如果你觉得你可以做得更好，那就去做吧。

[ 1 ] - 见2.3出版物
[ 2 ] - 参见3.7匹配资源方法请求

---

UPDATE

因此，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的情况下，它是泽西岛。

另一个混淆点可能出现在app配置中。 不是像在OP的帖子中那样使用web.xml，而是使用了一个Application子类。 就像是

@ApplicationPath("/rest")
public class AppConfig extends Application {
    ...
}

JAX-RS规范指出，当带有注释的此类可用时，应使用上述完全限定类名作为Servlet名创建Servlet，并将url映射为@ApplicationPath的值。 所以无论你使用什么实现，这种行为应该是相同的。

Answer 2

JAX-RS

JAX-RS是用于创建REST API的标准。 即使您可以构建像泽西这样的库来构建标准的实现。 JAX-RS是JEE等JavaEE堆栈的一部分。 所以像JBoss这样的应用服务器捆绑了jax-rs和jms。

为什么泽西？

JAX-RS没有与tomcat捆绑在一起。 Jersey可以使用像Tomcat，Jetty等servlet容器。这类似于ApacheMQ，可以使容器做JMS。 它旨在扩展servlet以创建休息端点。 它也是JAX-RS的一个实现。 实现该标准使其与为JAX-RS编写的代码一致。

备择方案

有apache-cxf ，它实现了JAX-RS，并且都有SOAP和REST。 我多年来一直在使用运动衫。 因为我喜欢和tomcat一起工作。 现在我们帮助构建metamug ，这是一个用于REST API的tomcat框架。

Answer 3

JAX-RS定义了一些标准和规则。 通常，Jersey是JAX-RS实现。

但更具体地说， Jersey是一个框架，不仅仅是JAX-RS参考实现。 Jersey提供了自己的API，通过其他功能和实用程序扩展了JAX-RS工具包，以进一步简化RESTful服务和客户端开发。