Tại sao sử dụng JAX-RS / Jersey?


84

Xin lỗi, câu hỏi này nghe có vẻ ngớ ngẩn, nhưng sau khi phát triển một số dịch vụ RESTful của mình bằng cách sử dụng Jersey, tôi đã tự hỏi mình câu hỏi - Nếu REST chỉ là một kiến ​​trúc và không phải là một giao thức như SOAP, tại sao chúng ta cần một đặc tả như JAX-RS?

Tôi thực sự đã tìm kiếm trên Google cho các câu hỏi như "Sự khác biệt giữa các dịch vụ servlet và RESTful qua HTTP" và để tổng hợp các câu trả lời của cộng đồng, tôi đã nhận được:

  1. Phát triển dịch vụ RESTful (trên Jersey) là một kiến ​​trúc, vốn sử dụng các servlet.
  2. Các công cụ tuân thủ JAX-RS như Jersey cung cấp dữ liệu XML / JSON dễ dàng sắp xếp-giải phóng dữ liệu XML / JSON, giúp các nhà phát triển.
  3. REST giúp chúng tôi sử dụng GET / POST / PUT / DELETE theo cách hiệu quả hơn nhiều so với các servlet bình thường.

Theo những câu trả lời này, tôi đoán nếu tôi viết một servlet sử dụng JAXB (để xử lý tuần tự hóa tự động) và tôi sử dụng hiệu quả GET / POST / PUT / DELETE trong mã servlet của mình, tôi không sử dụng một công cụ như Jersey và do đó JAX-RS.

Tôi biết tôi đã sai rất nhiều khi thông qua câu này, xin hãy sửa cho tôi.

Tái bút: Sự nghi ngờ này thực sự xuất hiện khi tôi phải phát triển một số dịch vụ RESTful trong PHP. Sau khi xem qua một số mã PHP RESTful, tôi nhận ra rằng chúng chỉ là các tập lệnh PHP cũ giống nhau, với một số phương thức trợ giúp để xử lý XML / JSON.


Cảm ơn sự phản hồi của bạn. Nhưng ai đó có thể chỉ trả lời điểm đầu tiên của tôi không? Tại sao chúng ta cần một đặc điểm kỹ thuật cho một "kiến trúc" ... có lẽ ai đó có thể chỉ cho tôi bất kỳ kiến ​​trúc nào khác cung cấp một thông số kỹ thuật chính thức?
WinOrWin

Bạn đang tìm kiếm nhiều lý do hơn là sự đơn giản (vài dòng mã) và tính di động (triển khai tới GlassFish, WebLogic, WebSphere, JBoss, v.v.)? Bạn có thể phát triển một dịch vụ RESTful bằng cách sử dụng các đặc tả cấp thấp hơn như Servlets / JAXP / JDBC, nhưng điều này thường liên quan đến nhiều mã hơn so với các thông số kỹ thuật cấp cao hơn như JAX-RS / JAXB / JPA.
bdoughan

Câu trả lời:


72

Tại sao sử dụng JAX-RS / Jersey?

Câu trả lời ngắn

Vì nó làm cho việc phát triển các dịch vụ RESTful dễ dàng hơn.

Câu trả lời dài

JAX-RS là một tiêu chuẩn giúp bạn dễ dàng tạo một dịch vụ RESTful có thể được triển khai cho bất kỳ máy chủ ứng dụng Java nào: GlassFish, WebLogic, WebSphere, JBoss, v.v.

JAX-RS là một phần của Java EE và khi JAX-RS được sử dụng với các công nghệ Java EE khác, việc tạo dịch vụ RESTful của bạn thậm chí còn dễ dàng hơn:

  • EJB - Một session bean được sử dụng như việc triển khai dịch vụ và cũng xử lý ngữ nghĩa giao dịch.
  • JAX-RS - Được sử dụng để hiển thị phiên đậu như một dịch vụ RESTful
  • JPA - Được sử dụng để duy trì POJO vào cơ sở dữ liệu. Lưu ý cách EntityManager được đưa vào trong session bean.
  • JAXB - Được sử dụng để chuyển đổi POJO sang / từ XML (trong GlassFish, nó cũng có thể được sử dụng để chuyển đổi POJO sang / từ JSON). JAX-RS theo mặc định xử lý tương tác với việc triển khai JAXB.

Dịch vụ JAX-RS mẫu

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

}

Để biết thêm thông tin:


Thuật ngữ "session bean" gây hiểu nhầm ở đây. Như mã của bạn hiển thị, điểm cuối RESTful được cho là không trạng thái. Không có phiên nào được lưu giữ.
phi

Vì vậy, JAX-RS thân thiện hơn với XML dựa trên cơ sở của bạn rằng chuyển đổi JSON chỉ khả dụng với máy chủ GlassFish? Cảm ơn
pixel

Bất cứ ai có thể nhận xét về sự khác biệt với Springboot? Tại sao lại sử dụng cái này hơn cái kia? Cảm ơn
pixel

58

REST là một kiến ​​trúc, vốn sử dụng các servlet.

Không có nó không phải là. REST là một kiểu kiến ​​trúc có thể được triển khai bằng các servlet, nhưng vốn dĩ không sử dụng chúng, cũng như không liên quan gì đến Java.

JAX-RS là một Đặc tả JSR xác định một API Java cho các Dịch vụ Web RESTful.

Jersey là một triển khai cụ thể của JAX-RS.

Về việc có nên sử dụng Jersey hay cố gắng tuân thủ đặc tả JAX-RS hay không, đó là tùy thuộc vào bạn. Nếu nó làm cho công việc của bạn dễ dàng hơn, tuyệt vời! Nếu không phải không ai ép buộc bạn.


12
+1 Lưu ý bổ sung: sử dụng JAX-RS gần như được đảm bảo sẽ dễ dàng hơn nhiều so với việc triển khai ReSTful của riêng bạn bằng các servlet. Đó là toàn bộ điểm của nó.
Ryan Stewart

@Ryan, Don: Đó là toàn bộ mục đích của câu hỏi này - Chúng ta có cần Jersey chỉ để giảm bớt các hoạt động được đề cập ở trên không. Và tôi biết JAX-RS là gì, tôi chỉ muốn biết tại sao những người Java lại cung cấp một API riêng cho việc này ... PHP không cung cấp bất kỳ cái nào và có vẻ như họ vẫn đang làm rất tốt.
WinOrWin

7
@WinOrWin: Chúng tôi cũng có thể làm mọi thứ trong lắp ráp, vậy tại sao lại sử dụng Java? Tất cả những gì tôi có thể nói là viết một API ReSTful theo cả hai cách và quyết định việc nào bạn muốn làm đi làm lại.
Ryan Stewart
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.