¿Por qué utilizar JAX-RS / Jersey?


84

Lo siento, esta pregunta suena tonta, pero después de desarrollar algunos de mis servicios RESTful usando Jersey, me hice la pregunta: si REST es solo una arquitectura y no un protocolo como SOAP, ¿por qué necesitamos una especificación como JAX-RS?

De hecho, busqué en Google preguntas como "¿Cuál es la diferencia entre servlets y servicios RESTful a través de HTTP" y, para resumir las respuestas de la comunidad, obtuve:

  1. El desarrollo de servicios RESTful (en Jersey) es una arquitectura que utiliza servlets de forma inherente.
  2. Las herramientas compatibles con JAX-RS, como Jersey, facilitan la clasificación y eliminación de datos XML / JSON, lo que ayuda a los desarrolladores.
  3. REST nos ayuda a usar GET / POST / PUT / DELETE de una manera mucho más eficiente que los servlets normales.

De acuerdo con estas respuestas, supongo que si escribo un servlet que usa JAXB (para lidiar con la serialización automática) y uso eficientemente GET / POST / PUT / DELETE en mi código de servlet, no uso una herramienta como Jersey, y de ahí JAX-RS.

Sé que estoy muy equivocado al aprobar esta declaración, por favor corríjame.

PD: Esta duda surgió cuando tuve que desarrollar algunos servicios RESTful en PHP. Después de pasar por algunos de los códigos PHP RESTful, me di cuenta de que son los mismos scripts PHP antiguos, con algunos métodos auxiliares para manejar XML / JSON.


Gracias por todas sus respuestas. Pero, ¿alguien puede responder a mi primer punto? ¿Por qué necesitamos una especificación para una "arquitectura" ... tal vez alguien pueda señalarme cualquier otra arquitectura que proporcione una especificación formal?
WinOrWin

¿Está buscando algo más que la simplicidad (pocas líneas de código) y la portabilidad (implementar en GlassFish, WebLogic, WebSphere, JBoss, etc.)? Puede desarrollar un servicio RESTful utilizando especificaciones de nivel inferior como Servlets / JAXP / JDBC, pero esto generalmente implica más código que especificaciones de nivel superior como JAX-RS / JAXB / JPA.
bdoughan

Respuestas:


72

¿Por qué utilizar JAX-RS / Jersey?

Respuesta corta

Porque facilita el desarrollo de servicios RESTful.

Respuesta larga

JAX-RS es un estándar que facilita la creación de un servicio RESTful que se puede implementar en cualquier servidor de aplicaciones Java: GlassFish, WebLogic, WebSphere, JBoss, etc.

JAX-RS es parte de Java EE, y cuando JAX-RS se usa con otras tecnologías Java EE, se vuelve aún más fácil crear su servicio RESTful:

  • EJB : un bean de sesión se utiliza como implementación del servicio y también maneja la semántica de la transacción.
  • JAX-RS : se utiliza para exponer el bean de sesión como un servicio RESTful
  • JPA : se utiliza para conservar los POJO en la base de datos. Observe cómo se inyecta EntityManager en el bean de sesión.
  • JAXB : se utiliza para convertir POJO a / desde XML (en GlassFish también se puede utilizar para convertir POJO a / desde JSON). JAX-RS maneja de forma predeterminada la interacción con la implementación JAXB.

Ejemplo de servicio 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();
    }

}

Para más información:


El término "bean de sesión" es engañoso aquí. Como muestra su código, se supone que el punto final RESTful no tiene estado. No se mantiene ninguna sesión.
phi

Entonces, ¿JAX-RS es más compatible con XML basado en su respuesta de que la conversión JSON solo está disponible con el servidor GlassFish? Gracias
pixel

¿Alguien podría comentar sobre la diferencia con Springboot? ¿Por qué usar uno sobre el otro? Gracias
pixel

58

REST es una arquitectura que utiliza servlets de forma inherente.

No, no es. REST es un estilo de arquitectura que se puede implementar usando servlets, pero no los usa inherentemente, ni tiene nada que ver inherentemente con Java.

JAX-RS es una especificación JSR que define una API Java para servicios web RESTful.

Jersey es una implementación específica de JAX-RS.

En cuanto a si usar Jersey o tratar de cumplir con la especificación JAX-RS, eso depende de usted. Si te facilita el trabajo, ¡genial! Si no, nadie te está obligando.


12
+1 Nota adicional: casi se garantiza que usar JAX-RS será mucho más fácil que implementar su propia implementación de ReSTful usando servlets. Ese es el objetivo.
Ryan Stewart

@ Ryan, Don: Ese es todo el propósito de esta pregunta: ¿necesitamos Jersey solo para facilitar las actividades mencionadas anteriormente? Y sé qué es JAX-RS, solo quiero saber por qué la gente de Java ofrece una API separada para esto ... PHP no ofreció ninguna y, al parecer, lo están haciendo bien.
WinOrWin

7
@WinOrWin: También podríamos hacer todo en ensamblador, entonces, ¿por qué usar Java? Todo lo que puedo decir es escribir una API ReSTful en ambos sentidos y decidir qué le gustaría hacer una y otra vez.
Ryan Stewart
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.