JAX-RS / Jersey를 사용하는 이유는 무엇입니까?


84

죄송합니다.이 질문은 어리석은 것처럼 들리지만 Jersey를 사용하여 일부 RESTful 서비스를 개발 한 후 스스로에게 질문했습니다. REST가 SOAP와 같은 프로토콜이 아닌 아키텍처 인 경우 왜 JAX-RS와 같은 사양이 필요한가요?

실제로 "HTTP를 통한 서블릿과 RESTful 서비스의 차이점"과 같은 질문을 검색하고 커뮤니티 답변을 요약하면 다음과 같은 결과를 얻었습니다.

  1. RESTful 서비스 개발 (저지에서)은 본질적으로 서블릿을 사용하는 아키텍처입니다.
  2. Jersey와 같은 JAX-RS 호환 도구는 XML / JSON 데이터를 쉽게 마샬링-언 마샬링하여 개발자를 지원합니다.
  3. REST는 일반 서블릿보다 훨씬 효율적인 방식으로 GET / POST / PUT / DELETE를 사용할 수 있도록 도와줍니다.

이 답변에 따르면 JAXB (자동 직렬화를 처리하기 위해)를 사용하는 서블릿을 작성하고 서블릿 코드에서 GET / POST / PUT / DELETE를 효율적으로 사용하면 Jersey와 같은 도구를 사용하지 않습니다. 따라서 JAX-RS.

나는이 진술을 전달하는 것이 매우 잘못되었다는 것을 알고 있습니다.

PS :이 의심은 실제로 PHP로 RESTful 서비스를 개발해야 할 때 발생했습니다. RESTful PHP 코드 중 일부를 살펴본 후, XML / JSON을 처리하기위한 몇 가지 도우미 메서드가있는 동일한 오래된 PHP 스크립트임을 깨달았습니다.


모든 답장에 감사드립니다. 그러나 누군가 내 첫 번째 요점에 대답 할 수 있습니까? "아키텍처"에 대한 사양이 필요한 이유는 무엇입니까? 누군가가 공식 사양을 제공하는 다른 아키텍처를 알려줄 수 있습니까?
WinOrWin

단순성 (몇 줄의 코드)과 이식성 (GlassFish, WebLogic, WebSphere, JBoss 등에 배포)보다 더 많은 이유를 찾고 있습니까? Servlets / JAXP / JDBC와 같은 하위 수준 사양을 사용하여 RESTful 서비스를 개발할 수 있지만 일반적으로 여기에는 JAX-RS / JAXB / JPA와 같은 상위 수준 사양보다 더 많은 코드가 포함됩니다.
bdoughan 2011-08-15

답변:


72

JAX-RS / Jersey를 사용하는 이유는 무엇입니까?

짧은 답변

RESTful 서비스를 더 쉽게 개발할 수 있기 때문입니다.

긴 답변

JAX-RS는 GlassFish, WebLogic, WebSphere, JBoss 등 모든 Java 애플리케이션 서버에 배포 할 수있는 RESTful 서비스를 쉽게 만들 수있는 표준입니다.

JAX-RS는 Java EE의 일부이며 JAX-RS를 다른 Java EE 기술과 함께 사용하면 RESTful 서비스를 훨씬 쉽게 만들 수 있습니다.

  • EJB- 세션 빈은 서비스 구현으로 사용되며 트랜잭션 의미 체계도 처리합니다.
  • JAX-RS- 세션 Bean을 RESTful 서비스로 노출하는 데 사용됩니다.
  • JPA- 데이터베이스에 POJO를 유지하는 데 사용됩니다. EntityManager가 세션 빈에 주입되는 방법에 유의하십시오.
  • JAXB -POJO를 XML로 /에서 변환하는 데 사용됩니다 (GlassFish에서 POJO를 JSON으로 /에서 변환하는데도 사용할 수 있음). 기본적으로 JAX-RS는 JAXB 구현과의 상호 작용을 처리합니다.

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

}

자세한 내용은:


여기서 "세션 빈"이라는 용어는 오해의 소지가 있습니다. 코드에서 알 수 있듯이 RESTful 엔드 포인트는 상태 비 저장이어야합니다. 보관 된 세션이 없습니다.
파이

그렇다면 JAX-RS는 GlassFish 서버에서만 JSON 변환을 사용할 수 있다는 확신을 바탕으로 XML에 더 친숙합니까? 감사합니다
픽셀

누구든지 Springboot와의 차이점에 대해 언급 할 수 있습니까? 왜 다른 하나를 사용합니까? 감사합니다
픽셀

58

REST는 본질적으로 서블릿을 사용하는 아키텍처입니다.

전혀 그렇지 않다. REST는 서블릿을 사용하여 구현할 수 있지만 본질적으로이를 사용하지 않으며 본질적으로 Java와 관련이없는 아키텍처 스타일입니다.

JAX-RS는 RESTful 웹 서비스 용 Java API를 정의하는 JSR 사양입니다.

Jersey는 JAX-RS의 특정 구현입니다.

Jersey를 사용할지 아니면 JAX-RS 사양을 준수할지 여부는 사용자에게 달려 있습니다. 작업이 더 쉬워 진다면 좋습니다! 아무도 당신을 강요하지 않는다면.


12
+1 추가 참고 : JAX-RS를 사용하는 것은 서블릿을 사용하여 자체 ReSTful 구현을 롤링하는 것보다 훨씬 쉬울 것입니다. 그게 전부입니다.
Ryan Stewart

@Ryan, Don : 이것이이 질문의 전체 목적입니다. 위에서 언급 한 활동을 쉽게하기 위해서만 Jersey가 필요합니까? 그리고 JAX-RS가 무엇인지 알고 있습니다. Java 사람들이 별도의 API를 제공하는 이유를 알고 싶습니다. PHP는 아무것도 제공하지 않았고 여전히 잘하고 있습니다.
WinOrWin 2011-08-13

7
@WinOrWin : 어셈블리에서도 모든 작업을 수행 할 수 있는데 왜 Java를 사용합니까? 제가 말할 수있는 것은 ReSTful API를 양방향으로 작성하고 반복해서 수행 할 작업을 결정하는 것입니다.
Ryan Stewart
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.