Reputation: 2117
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:
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.
Upvotes: 88
Views: 55769
Reputation: 148977
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:
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:
Upvotes: 74
Reputation: 41127
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.
Upvotes: 62