Dlaczego warto korzystać z JAX-RS / Jersey?

84

Przepraszam, to pytanie brzmi głupio, ale po opracowaniu niektórych moich usług RESTful przy użyciu Jersey, zadałem sobie pytanie - Jeśli REST jest tylko architekturą, a nie protokołem takim jak SOAP, po co nam specyfikacja taka jak JAX-RS?

Właściwie przeszukałem go w poszukiwaniu pytań typu „Jaka jest różnica między serwletami a usługami RESTful przez HTTP” i podsumowując odpowiedzi społeczności, otrzymałem:

  1. Rozwój usług RESTful (na Jersey) to architektura, która z natury korzysta z serwletów.
  2. Narzędzia zgodne z JAX-RS, takie jak Jersey, zapewniają łatwe krosowanie i usuwanie danych XML / JSON, pomagając programistom.
  3. REST pomaga nam używać GET / POST / PUT / DELETE w sposób znacznie skuteczniejszy niż zwykłe serwlety.

Zgodnie z tymi odpowiedziami, myślę, że jeśli napiszę serwlet, który używa JAXB (do obsługi automatycznej serializacji) i wydajnie używam GET / POST / PUT / DELETE w moim kodzie serwletu, nie używam narzędzia takiego jak Jersey i stąd JAX-RS.

Wiem, że bardzo się mylę, przekazując to oświadczenie, popraw mnie.

PS: Ta wątpliwość pojawiła się, kiedy musiałem opracować usługi RESTful w PHP. Po przejrzeniu niektórych kodów PHP RESTful, zdałem sobie sprawę, że są to te same stare skrypty PHP, z kilkoma pomocniczymi metodami obsługi XML / JSON.

WinOrWin
źródło
Dzięki za wszystkie twoje odpowiedzi. Ale czy ktoś może po prostu odpowiedzieć na mój pierwszy punkt? Dlaczego potrzebujemy specyfikacji dla „architektury” ... może ktoś może wskazać mi inną architekturę, która dostarcza formalną specyfikację?
WinOrWin
Szukasz czegoś więcej niż prostoty (kilka linii kodu) i przenośności (wdrażanie w GlassFish, WebLogic, WebSphere, JBoss itp.)? Usługę zgodną z REST można opracować przy użyciu specyfikacji niższego poziomu, takich jak serwlety / JAXP / JDBC, ale zazwyczaj obejmuje to więcej kodu niż specyfikacje wyższego poziomu, takie jak JAX-RS / JAXB / JPA.
bdoughan

Odpowiedzi:

72

Dlaczego warto korzystać z JAX-RS / Jersey?

Krótka odpowiedź

Ponieważ ułatwia tworzenie usług RESTful.

Długa odpowiedź

JAX-RS to standard ułatwiający tworzenie usług zgodnych z REST, które można wdrożyć na dowolnym serwerze aplikacji Java: GlassFish, WebLogic, WebSphere, JBoss itp.

JAX-RS jest częścią Java EE, a gdy JAX-RS jest używany z innymi technologiami Java EE, tworzenie usługi RESTful staje się jeszcze łatwiejsze:

  • EJB - komponent bean sesji jest używany jako implementacja usługi, a także obsługuje semantykę transakcji.
  • JAX-RS - służy do ujawniania komponentu bean sesji jako usługi RESTful
  • JPA - Służy do utrwalania POJO w bazie danych. Zwróć uwagę, jak EntityManager jest wstrzykiwany do komponentu bean sesji.
  • JAXB - Służy do konwersji POJO do / z XML (w GlassFish można go również użyć do konwersji POJO do / z JSON). JAX-RS domyślnie obsługuje interakcję z implementacją JAXB.

Przykładowa usługa 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();
    }

}

Po więcej informacji:

bdoughan
źródło
Termin „ziarno sesyjne” jest tutaj mylący. Jak pokazuje Twój kod, punkt końcowy RESTful powinien być bezstanowy. Nie ma żadnej sesji.
phi
Tak więc, JAX-RS jest bardziej przyjazny dla XML, na podstawie twojej odpowiedzi, że konwersja JSON jest dostępna tylko na serwerze GlassFish? Dzięki
pixel
Czy ktoś mógłby wypowiedzieć się na temat różnicy w Springboot? Po co używać jednego nad drugim? Dzięki
pixel
58

REST to architektura, która z natury korzysta z serwletów.

Nie, nie jest. REST to styl architektury, który można zaimplementować za pomocą serwletów, ale nie używa ich z natury ani nie ma nic wspólnego z Javą.

JAX-RS to specyfikacja JSR definiująca interfejs API języka Java dla usług WWW zgodnych z REST.

Jersey to specyficzna implementacja JAX-RS.

To, czy używać Jersey, czy starać się zachować zgodność ze specyfikacją JAX-RS, zależy od Ciebie. Jeśli to ułatwi Ci pracę, to świetnie! Jeśli nie, nikt cię nie zmusza.

Don Roby
źródło
12
+1 Dodatkowa uwaga: korzystanie z JAX-RS jest prawie na pewno dużo łatwiejsze niż toczenie własnej implementacji ReSTful przy użyciu serwletów. O to właśnie chodzi.
Ryan Stewart
@Ryan, Don: To jest cały cel tego pytania - Czy potrzebujemy Jersey tylko po to, aby ułatwić wyżej wymienione czynności. Wiem, co to jest JAX-RS, chcę tylko wiedzieć, dlaczego ludzie zajmujący się Javą oferują do tego oddzielne API ... PHP nie oferowało żadnego, a mimo to wydaje się, że radzą sobie dobrze.
WinOrWin
7
@WinOrWin: Moglibyśmy zrobić wszystko w asemblerze, więc po co używać Javy? Wszystko, co mogę powiedzieć, to napisać ReSTful API w obie strony i zdecydować, co chcesz robić w kółko.
Ryan Stewart