Sorry, this questions sounds silly, but after developing some of my RESTful services using Jersey, I asked myself the question -- If REST is just an architecture, and not a protocol like SOAP, why do we need a specification like JAX-RS?
I actually googled for questions like "What is the difference between servlets and RESTful services over HTTP" and to sum up the community answers, I got:
RESTful service development (on Jersey) is an architecture, which inherently uses servlets. JAX-RS compliant tools like Jersey provide easy marshalling-unmarshalling of XML/JSON data, helping the developers. REST helps us use GET/POST/PUT/DELETE in a fashion that is far efficient than normal servlets.
According to these answers, I guess if I write a servlet which uses JAXB (for dealing with automatic serialization), and I efficiently use GET/POST/PUT/DELETE in my servlet code, I don't use a tool like Jersey, and hence JAX-RS.
I know I am terribly wrong passing this statement, please correct me.
PS: This doubt actually came in when I had to develop some RESTful services in PHP. After going on through some of the RESTful PHP codes, I realized they are just the same old PHP scripts, with some helper methods for handling XML/JSON.
Why use JAX-RS / Jersey?
Short Answer
Because it makes the development of RESTful services easier.
Long Answer
JAX-RS is a standard that makes it easy to create a RESTful service that can be deployed to any Java application server: GlassFish, WebLogic, WebSphere, JBoss, etc.
JAX-RS is part of Java EE, and when JAX-RS is used with other Java EE technologies it becomes even easier to create your RESTful service:
EJB - A session bean is used as the service implementation and also handles the transaction semantics.
JAX-RS - Used to expose the session bean as a RESTful service
JPA - Used to persist the POJOs to the database. Note how the EntityManager is injected onto the session bean.
JAXB - Used to convert the POJO to/from XML (in GlassFish it can also be used to convert the POJO to/from JSON). JAX-RS by default handles the interaction with the JAXB implementation.
Sample JAX-RS Service
package org.example;
import java.util.List;
import javax.ejb.*;
import javax.persistence.*;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
@Stateless
@LocalBean
@Path("/customers")
public class CustomerService {
@PersistenceContext(unitName="CustomerService",
type=PersistenceContextType.TRANSACTION)
EntityManager entityManager;
@POST
@Consumes(MediaType.APPLICATION_XML)
public void create(Customer customer) {
entityManager.persist(customer);
}
@GET
@Produces(MediaType.APPLICATION_XML)
@Path("{id}")
public Customer read(@PathParam("id") long id) {
return entityManager.find(Customer.class, id);
}
@PUT
@Consumes(MediaType.APPLICATION_XML)
public void update(Customer customer) {
entityManager.merge(customer);
}
@DELETE
@Path("{id}")
public void delete(@PathParam("id") long id) {
Customer customer = read(id);
if(null != customer) {
entityManager.remove(customer);
}
}
@GET
@Produces(MediaType.APPLICATION_XML)
@Path("findCustomersByCity/{city}")
public List<Customer> findCustomersByCity(@PathParam("city") String city) {
Query query = entityManager.createNamedQuery("findCustomersByCity");
query.setParameter("city", city);
return query.getResultList();
}
}
For More Information:
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-45.html
REST is an architecture, which inherently uses servlets.
No, it is not. REST is an architecture style which can be implemented using servlets, but does not inherently use them, nor inherently have anything to do with Java.
JAX-RS is a JSR Specification defining a Java API for RESTful Web Services.
Jersey is a specific implementation of JAX-RS.
As to whether to use Jersey or try to be compliant to the JAX-RS specification, that's sort of up to you. If it makes your work easier, great! If not no one's forcing you.
Success story sharing