Désolé, cette question semble idiote, mais après avoir développé certains de mes services RESTful à l'aide de Jersey, je me suis posé la question - Si REST n'est qu'une architecture, et non un protocole comme SOAP, pourquoi nous avons besoin d'une spécification comme JAX-RS?
J'ai fait une recherche sur Google pour des questions comme "Quelle est la différence entre les servlets et les services RESTful sur HTTP" et pour résumer les réponses de la communauté, j'ai obtenu:
D'après ces réponses, je suppose que si j'écris un servlet qui utilise JAXB (pour gérer la sérialisation automatique), et que j'utilise efficacement GET/POST/PUT/DELETE dans mon code de servlet, je n'utilise pas un outil comme Jersey, et d'où JAX-RS.
Je sais que je me trompe terriblement en passant cette déclaration, veuillez me corriger.
PS: Ce doute est venu quand j'ai dû développer des services RESTful en PHP. Après avoir parcouru certains des codes RESTful PHP, j'ai réalisé qu'ils étaient exactement les mêmes anciens scripts PHP, avec quelques méthodes d'assistance pour gérer XML/JSON).
Pourquoi utiliser JAX-RS/Jersey?
Réponse courte
Parce que cela facilite le développement des services RESTful.
Réponse longue
JAX-RS est une norme qui facilite la création d'un service RESTful qui peut être déployé sur n'importe quel Java: GlassFish, WebLogic, WebSphere, JBoss, etc.
JAX-RS fait partie de Java EE, et lorsque JAX-RS est utilisé avec d'autres technologies Java EE, il devient encore plus facile de créer votre service RESTful:
Exemple de service JAX-RS
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();
}
}
Pour plus d'informations:
REST est une architecture qui utilise intrinsèquement des servlets.
Non, ça ne l'est pas. REST est un style d'architecture qui peut être implémenté à l'aide de servlets, mais ne les utilise pas de manière inhérente, ni n'a rien à voir avec Java.
JAX-RS est une spécification JSR définissant une Java pour les services Web RESTful.
Jersey est une implémentation spécifique de JAX-RS.
Quant à savoir si vous souhaitez utiliser Jersey ou essayer d'être conforme à la spécification JAX-RS, cela dépend de vous. Si cela facilite votre travail, tant mieux! Si personne ne vous force.