Por que usar JAX-RS / Jersey?


84

Desculpe, essa pergunta parece boba, mas depois de desenvolver alguns dos meus serviços RESTful usando Jersey, me perguntei - Se REST é apenas uma arquitetura, e não um protocolo como SOAP, por que precisamos de uma especificação como JAX-RS?

Na verdade, pesquisei no Google por questões como "Qual é a diferença entre servlets e serviços RESTful sobre HTTP" e, para resumir as respostas da comunidade, obtive:

  1. O desenvolvimento de serviço RESTful (em Jersey) é uma arquitetura que usa servlets inerentemente.
  2. Ferramentas compatíveis com JAX-RS, como Jersey, fornecem fácil empacotamento e descompressão de dados XML / JSON, ajudando os desenvolvedores.
  3. REST nos ajuda a usar GET / POST / PUT / DELETE de uma maneira muito eficiente do que servlets normais.

De acordo com essas respostas, acho que se eu escrever um servlet que usa JAXB (para lidar com a serialização automática) e usar GET / POST / PUT / DELETE em meu código de servlet, não uso uma ferramenta como Jersey e daí JAX-RS.

Sei que estou terrivelmente errado ao passar esta afirmação, corrija-me.

PS: Essa dúvida realmente surgiu quando tive que desenvolver alguns serviços RESTful em PHP. Depois de passar por alguns dos códigos PHP RESTful, percebi que são apenas os mesmos scripts PHP antigos, com alguns métodos auxiliares para lidar com XML / JSON.


Obrigado por todas as suas respostas. Mas alguém pode simplesmente responder ao meu primeiro ponto? Por que precisamos de uma especificação para uma "arquitetura" ... talvez alguém possa simplesmente indicar-me qualquer outra arquitetura que forneça uma especificação formal?
WinOrWin de

Você está procurando mais um motivo do que simplicidade (poucas linhas de código) e portabilidade (implantar no GlassFish, WebLogic, WebSphere, JBoss, etc)? Você pode desenvolver um serviço RESTful usando especificações de nível inferior, como Servlets / JAXP / JDBC, mas isso geralmente envolve mais código do que especificações de nível superior, como JAX-RS / JAXB / JPA.
bdoughan de

Respostas:


72

Por que usar JAX-RS / Jersey?

Resposta curta

Porque facilita o desenvolvimento de serviços RESTful.

Resposta longa

JAX-RS é um padrão que facilita a criação de um serviço RESTful que pode ser implantado em qualquer servidor de aplicativos Java: GlassFish, WebLogic, WebSphere, JBoss, etc.

JAX-RS faz parte do Java EE, e quando JAX-RS é usado com outras tecnologias Java EE, torna-se ainda mais fácil criar seu serviço RESTful:

  • EJB - Um bean de sessão é usado como a implementação do serviço e também lida com a semântica da transação.
  • JAX-RS - usado para expor o bean de sessão como um serviço RESTful
  • JPA - usado para persistir os POJOs no banco de dados. Observe como o EntityManager é injetado no bean de sessão.
  • JAXB - Usado para converter o POJO de / para XML (no GlassFish também pode ser usado para converter o POJO de / para JSON). JAX-RS por padrão lida com a interação com a implementação JAXB.

Serviço JAX-RS de amostra

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 maiores informações:


O termo "bean de sessão" é enganoso aqui. Como mostra seu código, o ponto de extremidade RESTful deve ser sem estado. Não há sessão mantida.
phi

Então, JAX-RS é mais amigável para XML com base na sua pergunta de que a conversão JSON está disponível apenas com o servidor GlassFish? Obrigado
pixel

Alguém poderia comentar sobre a diferença com o Springboot? Por que usar um em vez do outro? Obrigado
pixel

58

REST é uma arquitetura que usa servlets inerentemente.

Não não é. REST é um estilo de arquitetura que pode ser implementado usando servlets, mas não os usa inerentemente, nem tem nada a ver com Java.

JAX-RS é uma especificação JSR que define uma API Java para serviços da web RESTful.

Jersey é uma implementação específica de JAX-RS.

Quanto a usar Jersey ou tentar ser compatível com a especificação JAX-RS, isso depende de você. Se isso facilita o seu trabalho, ótimo! Se não, ninguém está te forçando.


12
+1 Nota adicional: usar JAX-RS é quase garantido como muito mais fácil do que lançar sua própria implementação ReSTful usando servlets. Esse é o ponto principal.
Ryan Stewart

@Ryan, Don: Esse é todo o propósito desta pergunta - precisamos de Jersey apenas para facilitar as atividades mencionadas acima. E eu sei o que é JAX-RS, eu só quero saber por que o pessoal de Java oferece uma API separada para isso ... PHP não ofereceu nenhuma e ainda assim eles estão indo bem, parece.
WinOrWin

7
@WinOrWin: Poderíamos fazer tudo em assembly também, então por que usar Java? Tudo o que posso dizer é escrever uma API ReSTful nos dois sentidos e decidir qual você gostaria de fazer repetidamente.
Ryan Stewart de
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.