与JAX-RS的混淆和与JAX-RS的球衣的混淆

与JAX-RS的混淆和与JAX-RS的球衣的混淆

JAX-RS指定围绕Servlets [ 1
]的部署模型。为什么，因为在Java世界中，这就是运行Web应用程序的方式。请求进入Servlet容器（例如Tomcat或完整的Java
EE服务器中的容器），该容器将请求移交给Servlet应用程序，应用程序处理该请求并将响应发送回该容器，然后将其发送给客户。Spring
MVC是一个基于Servlet的框架（主要Servlet是

DispatcherServlet

）。JSF是一个基于Servlet的框架（主要Servlet是

FacesServlet

）。围绕Servlet构建JAX-
RS的方式相同（主要Servlet特定于实现；对于Jersey而言是

ServletContainer

）。

请求进入Tomcat，它查找servlet映射，找到

ServletContainer

与请求URL匹配的内容，将请求包装在中，然后将其发送

HttpServletRequest

给Jersey
Servlet。现在，Jersey可以随心所欲地进行处理，这需要大量的处理；例如处理与您的方法[ 2
]匹配的请求，反序列化实体主体，以及使其他所有功能变为可能的其他功能。处理完成后，它将响应发送回容器。

为什么球衣使用servlet？

我认为以上已经阐明。

JAX-RS不使用servlet？

不确定我是否真的理解您的要求，但是JAX-
RS指定了其他部署模型，但是Servlet环境是唯一具有任何特定需求详细信息的环境。其他部署选项，例如在SE环境中，将是特定于实现的[ 1 ]。

为什么使用JAX-RS，而我们只能使用Servlet

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

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

---

更新

因此，在OP上造成困惑的部分原因是他正在阅读的教程没有在web.xml文件中指定Servlet，这使OP认为“香草JAX-RS”（
（不存在）正在使用，而ant不是实现。

JAX-RS只是一个规范，没有实现就无法运行。是的，有一个

javax.ws.rx-api.jar

或一个

javaee-api.jar

具有用于 编译
JAX-RS应用程序的类/接口/注释，但是此jar中没有实际的“引擎”。实际的JAX-RS“引擎”位于特定的实现罐中。

我还没有看完整的教程，但是我假设它使用了上面的jar之一，这使OP相信没有使用JAX-RS实现。但是实际上，使用的Java
EE服务器（即Glassfish）在内部具有实现。如果是Glassfish，则为泽西岛。

另一个困惑点可能是在应用程序配置中。与其在OP的帖子中不使用web.xml，而是使用了一个

Application

子类。就像是

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

JAX-
RS规范指出，当带有注释的此类可用时，应使用上述完全限定的类名称作为Servlet名称来创建Servlet，并且将映射到的url为的值

@ApplicationPath

。因此，无论您使用哪种实现，此行为都应该相同。