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:
- Rozwój usług RESTful (na Jersey) to architektura, która z natury korzysta z serwletów.
- Narzędzia zgodne z JAX-RS, takie jak Jersey, zapewniają łatwe krosowanie i usuwanie danych XML / JSON, pomagając programistom.
- 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.
Odpowiedzi:
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:
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:
źródło
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.
źródło