Confusion with JAX-RS and Jersey with JAX-RS

Question

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>

And then I have the annotation which is same as JAX-RS , on the GET I can call my service with correct URL.

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.

Answer 1

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 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.

why jersey using a servlet?

I think that is made clear above.

JAX-RS not using a servlet?

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].

Why using JAX-RS, while we can use a just Servlet

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] - See 2.3 Publication
[2] - See 3.7 Matching Requests to Resource Methods

---

UPDATE

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 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.

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.

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 {
    ...
}

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.

Answer 2

JAX-RS

JAX-RS is a standard for creating REST APIs. Even you can build a library like jersey to build an implementation of the standard. JAX-RS is part of the JavaEE stack like JMS and others. So application servers like JBoss come bundled with jax-rs and jms.

Why Jersey?

JAX-RS doesn't come bundled with tomcat. Jersey can work with servlet containers like Tomcat, Jetty etc. This is similar to ApacheMQ which can make containers do JMS. It is designed to extend servlets to create rest endpoints. It is also an implementation of JAX-RS. Implementing the standard makes it consistent with code written for JAX-RS.

Alternatives

There is apache-cxf, which implements JAX-RS and does SOAP & REST both. I have been using jersey myself for years. Since I liked working with tomcat. Now we help built metamug, a framework on tomcat for REST APIs with XML.

Answer 3

JAX-RS defines some standard and rules. In general Jersey is a JAX-RS implementation.

But more specifically Jersey is a framework is more than the JAX-RS reference implementation. Jersey provides its own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development.