Question

我真的很困惑。我已经尝试了一个带有tomcat的Jax-rs并使用了所有注释，我可以使用url来调用我的服务。所以没有Jax-rs，我可以简单地拥有一个servlet并调用我的服务。另外，正如我所尝试的，那里有jersey-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 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的情况下，它是泽西岛。

另一个混淆点可能出现在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＆amp;休息两者。我多年来一直在使用运动衫。因为我喜欢和tomcat一起工作。现在我们帮助构建metamug，一个用于REST API的tomcat框架和XML。

Answer 3

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

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

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

3 个答案:

更新

JAX-RS

为什么选择泽西？

替代