混淆 JAX-RS 和 Jersey 与 JAX-RS
我真的很困惑.我尝试了一个带有 tomcat 的 Jax-rs，并使用了我能够使用 url 调用我的服务的所有注释.因此，如果没有 Jax-rs，我可以简单地拥有一个 servlet 并调用我的服务.同样正如我所尝试的那样，有带有球衣的 jax-rs(正如我研究了它的 JAX-RS 的实现)，并且在 web.xml 中有以下内容.
I'm really confused of this. I have tried a Jax-rs with a tomcat and using all the annotations i was able to call my service using a url. So without Jax-rs I can simply have a servlet and call my service. Also as I have tried, there's jax-rs with jersey(As I have researched its a implementation of JAX-RS ) and in the web.xml theres following.
<!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 调用我的服务.
And then I have the annotation which is same as JAX-RS , on the GET I can call my service with correct URL.
我的问题是，为什么 jersey 使用 servlet?JAX-RS 不使用 servlet 吗?为什么要使用 JAX-RS，而我们可以只使用 Servlet.
My question is, why jersey using a servlet? JAX-RS not using a servlet ? Why using JAX-RS, while we can use a just Servlet.
推荐答案
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).
JAX-RS specifies a deployment model around Servlets[1]. Why, because in the Java world, that's how web applications are run. Request comes in to a Servlet container (like Tomcat or a container in a full Java EE server), the container hands off the request to the Servlet application, the application processes the request and spits out the response back to the container, which sends it to the client. Spring MVC is a Servlet based framework (main Servlet being DispatcherServlet). JSF is a Servlet based framework (main Servlet is FacesServlet). Same way JAX-RS is build around Servlets (main Servlet is implementation specific; in the case of Jersey it's ServletContainer).
Request 进入 Tomcat，它查找 servlet 映射，发现 ServletContainer 与请求 URL 匹配，它将请求包装在 HttpServletRequest 中并将其发送到泽西 Servlet.现在 Jersey 可以随心所欲地处理它，这是一个很大的处理过程；例如处理请求以匹配您的方法[2]、反序列化实体主体以及一大堆其他使所有魔法成为可能的东西.完成处理后，它会将响应发送回容器.
Request comes in to Tomcat, it looks up the servlet mappings, it finds ServletContainer matches the request URL, it wraps the request in a HttpServletRequest and ships it off to the Jersey Servlet. Now Jersey can do with it as it pleases, which is a whole lot of processing; such as processing the request to match your methods[2], deserializing entity bodies, and a whole bunch of other stuff that makes all the magic possible. When it's done processing, it send the response back to the container.
为什么 jersey 使用 servlet?
why jersey using a servlet?
我认为上面已经说得很清楚了.
I think that is made clear above.
JAX-RS 不使用 servlet?
JAX-RS not using a servlet?
不太确定我是否真的理解您的要求，但 JAX-RS 指定了其他部署模型，但 Servlet 环境是唯一具有任何特定要求细节的环境.其他部署选项(例如在 SE 环境中)将是特定于实施的[1].
Not really sure I really understand what you're asking by this, but JAX-RS specifies other deployment models, but a Servlet environment is the only one with any specific requirement details. Other deployment options, like in an SE environment will be implementation specific[1].
为什么要使用 JAX-RS，而我们可以只使用 Servlet
Why using JAX-RS, while we can use a just Servlet
您基本上是在问，当我可以实现自己的 REST 框架时，为什么还要使用 JAX-RS?".通常，当有可用的框架时，使用它.如果你觉得你可以做得更好，那就去做吧.
You're basically asking, "Why should I use JAX-RS, when I can implement my own REST framework?". Generally, when there is a framework available, use it. If you feel you can make a better one, then do it.
[1] - 参见 2.3 出版物
[2] - 参见 3.7 匹配资源请求方法
[1] - See 2.3 Publication
[2] - See 3.7 Matching Requests to Resource Methods
因此，部分 OP 的部分困惑是，他正在阅读的教程没有在 web.xml 文件中指定 Servlet，这使得 OP 认为vanilla JAX-RS";(不存在)正在使用，ant不是实现.
So part of the confusion on part of the OP, was that the tutorial he was going through, didn't specify the a Servlet in a web.xml file, which made the OP think that a "vanilla JAX-RS" (which doesn't exist) was being used, ant not an implementation.
JAX-RS 只是一个规范，没有实现就无法运行.是的，有一个 javax.ws.rx-api.jar 或一个 javaee-api.jar 具有要编译 一个 JAX-RS 应用程序，但没有实际的引擎"；在这个罐子里.实际的 JAX-RS 引擎"在具体的实现jar中.
JAX-RS is just a specification, and cannot run without an implementation. Yes there is a javax.ws.rx-api.jar or a javaee-api.jar that has the classes/interfaces/annotations to compile a JAX-RS application, but there is no actual "engine" in this jar. The actual JAX-RS "engine" is in the specific implementation jars.
我没有看过完整的教程，但我假设它使用了上述 jar 之一，这导致 OP 相信没有使用 JAX-RS 实现.但实际上，使用的 Java EE 服务器(即 Glassfish)在内部具有实现.对于 Glassfish，它是泽西岛.
I haven't watched the complete tutorial, but I assume that it uses one of the above jars, which led the OP to believe that no JAX-RS implementation is used. But in actuality, the Java EE server used (which is Glassfish), internally has the implementation. In the case of Glassfish it's Jersey.
另一个混淆点可能是应用配置.而不是在 OP 的帖子中使用 web.xml，而是使用了一个 Application 子类.类似的东西
Another point of confusion may have been in the app configuration. Instead of using a web.xml as in the OP's post, there is an Application subclass being used. Something like
@ApplicationPath("/rest")
public class AppConfig extends Application {
...
}
JAX-RS 规范规定，当这个带有注解的类可用时，应创建一个 Servlet，并将上述完全限定的类名作为 Servlet 名称，并且映射的 url 是 @ApplicationPath 中的值.所以无论你使用什么实现，这个行为应该是一样的.
The JAX-RS specification states that when this class with annotation is available, a Servlet should be created with the above fully qualified class name as the Servlet name, and the url mapping the be the value in the @ApplicationPath. So whatever implementation you are using, this behavior should be the same.
相关文章