Neden JAX-RS / Jersey kullanmalı?


85

Üzgünüm, bu soru kulağa aptalca geliyor, ancak Jersey kullanarak bazı RESTful servislerimi geliştirdikten sonra kendime şu soruyu sordum: REST sadece bir mimari ise ve SOAP gibi bir protokol değilse, neden JAX-RS gibi bir spesifikasyona ihtiyacımız var?

Aslında "HTTP üzerinden sunucu uygulamaları ile RESTful hizmetleri arasındaki fark nedir" gibi sorular için Google'da arama yaptım ve topluluğun yanıtlarını özetlemek için:

  1. RESTful service development (Jersey'de), doğal olarak sunucu uygulamalarını kullanan bir mimaridir.
  2. Jersey gibi JAX-RS uyumlu araçlar, geliştiricilere yardımcı olarak XML / JSON verilerinin kolayca sıralanmasını ve ayrıştırılmasını sağlar.
  3. REST, GET / POST / PUT / DELETE'i normal sunucu uygulamalardan çok daha verimli bir şekilde kullanmamıza yardımcı olur.

Bu cevaplara göre, sanırım JAXB (otomatik serileştirme ile uğraşmak için) kullanan bir sunucu uygulaması yazarsam ve servlet kodumda GET / POST / PUT / DELETE'i verimli bir şekilde kullanırsam, Jersey gibi bir araç kullanmıyorum ve dolayısıyla JAX-RS.

Bu açıklamayı yaparken çok yanlış olduğumu biliyorum, lütfen beni düzeltin.

Not: Bu şüphe aslında PHP'de bazı RESTful hizmetleri geliştirmem gerektiğinde ortaya çıktı. Bazı RESTful PHP kodlarının üzerinden geçtikten sonra, bunların aynı eski PHP betikleri olduklarını ve XML / JSON'u işlemek için bazı yardımcı yöntemler olduğunu fark ettim.


Tüm cevaplarınız için teşekkürler. Ama birisi ilk noktama cevap verebilir mi? Neden bir "mimari" için bir şartnameye ihtiyacımız var ... belki birisi beni resmi bir şartname sağlayan başka bir mimariye yönlendirebilir?
WinOrWin

Basitlikten (birkaç satır kod) ve taşınabilirlikten (GlassFish, WebLogic, WebSphere, JBoss, vb. İçin dağıtım) daha fazla bir neden mi arıyorsunuz? Servletler / JAXP / JDBC gibi daha düşük seviyeli spesifikasyonları kullanarak bir RESTful servisi geliştirebilirsiniz, ancak bu genellikle JAX-RS / JAXB / JPA gibi daha yüksek seviyeli spesifikasyonlardan daha fazla kod içerir.
bdoughan

Yanıtlar:


72

Neden JAX-RS / Jersey kullanmalı?

Kısa cevap

Çünkü RESTful servislerinin geliştirilmesini kolaylaştırır.

Uzun cevap

JAX-RS, herhangi bir Java uygulama sunucusuna dağıtılabilen bir RESTful hizmeti oluşturmayı kolaylaştıran bir standarttır: GlassFish, WebLogic, WebSphere, JBoss, vb.

JAX-RS, Java EE'nin bir parçasıdır ve JAX-RS diğer Java EE teknolojileriyle birlikte kullanıldığında RESTful hizmetinizi oluşturmak daha da kolay hale gelir:

  • EJB - Hizmet uygulaması olarak bir oturum fasulyesi kullanılır ve aynı zamanda işlem anlamını yönetir.
  • JAX-RS - Oturum beanini bir RESTful hizmet olarak göstermek için kullanılır
  • JPA - POJO'ları veritabanında tutmak için kullanılır. EntityManager'ın oturum parçacığına nasıl enjekte edildiğine dikkat edin.
  • JAXB - POJO'yu XML'e / XML'den dönüştürmek için kullanılır (GlassFish'te POJO'yu JSON'a / JSON'dan dönüştürmek için de kullanılabilir). JAX-RS varsayılan olarak JAXB uygulamasıyla etkileşimi yönetir.

Örnek JAX-RS Hizmeti

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

}

Daha fazla bilgi için:


"Seans fasulyesi" terimi burada yanıltıcıdır. Kodunuzun gösterdiği gibi, RESTful uç noktasının durumsuz olması gerekir. Tutulan oturum yok.
phi

Yani JAX-RS, JSON dönüşümünün yalnızca GlassFish sunucusu ile kullanılabildiğine dair asnwer'ınıza göre daha XML dostu mu? Teşekkürler
pixel

Springboot ile fark hakkında yorum yapan var mı? Neden biri diğerinin üzerinde kullanılıyor? Teşekkürler
pixel

58

REST, doğal olarak sunucu uygulamalarını kullanan bir mimaridir.

Hayır öyle değil. REST, sunucu uygulamaları kullanılarak gerçekleştirilebilen, ancak bunları doğası gereği kullanmayan veya doğası gereği Java ile bir ilgisi olmayan bir mimari stildir.

JAX-RS, RESTful Web Servisleri için bir Java API tanımlayan bir JSR Spesifikasyonudur.

Jersey, JAX-RS'nin özel bir uygulamasıdır.

Jersey'i kullanıp kullanmayacağınıza veya JAX-RS spesifikasyonuna uygun olmaya çalışıp çalışmayacağınıza gelince, bu biraz size kalmış. İşinizi kolaylaştıracaksa harika! Eğer kimse seni zorlamıyorsa.


12
+1 Ek not: JAX-RS kullanımının, kendi ReSTful uygulamanızı servletler kullanarak döndürmekten çok daha kolay olacağı neredeyse garantidir. Bütün mesele bu.
Ryan Stewart

@Ryan, Don: Bu sorunun tüm amacı bu - Jersey'e sadece yukarıda belirtilen faaliyetleri kolaylaştırmak için mi ihtiyacımız var? Ve JAX-RS'nin ne olduğunu biliyorum, sadece Java insanlarının neden bunun için ayrı bir API sunduğunu bilmek istiyorum ... PHP hiç sunmadı ve hala iyi gidiyorlar gibi görünüyor.
WinOrWin

7
@WinOrWin: Her şeyi montajda da yapabilirdik, öyleyse neden Java kullanalım? Söyleyebileceğim tek şey, her iki şekilde de bir ReSTful API yazmak ve hangisini defalarca yapmak istediğinize karar vermek.
Ryan Stewart
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.