Зачем использовать JAX-RS / Jersey?


85

Извините, этот вопрос звучит глупо, но после разработки некоторых из моих служб RESTful с использованием Джерси я задал себе вопрос: если REST - это просто архитектура, а не протокол типа SOAP, зачем нам нужна спецификация, такая как JAX-RS?

На самом деле я искал в Google такие вопросы, как «В чем разница между сервлетами и службами RESTful через HTTP», и, подытоживая ответы сообщества, я получил:

  1. Разработка сервисов RESTful (на Джерси) - это архитектура, которая по своей сути использует сервлеты.
  2. Совместимые с JAX-RS инструменты, такие как Jersey, обеспечивают простой маршаллинг-демаршалинг данных XML / JSON, помогая разработчикам.
  3. REST помогает нам использовать GET / POST / PUT / DELETE намного эффективнее, чем обычные сервлеты.

Согласно этим ответам, я предполагаю, что если я напишу сервлет, который использует JAXB (для работы с автоматической сериализацией), и я эффективно использую GET / POST / PUT / DELETE в своем коде сервлета, я не использую такой инструмент, как Jersey, и отсюда JAX-RS.

Я знаю, что я ужасно ошибаюсь, передавая это утверждение, пожалуйста, поправьте меня.

PS: Это сомнение на самом деле возникло, когда мне пришлось разрабатывать некоторые RESTful-сервисы на PHP. Пройдя через некоторые PHP-коды RESTful, я понял, что это те же самые старые PHP-скрипты с некоторыми вспомогательными методами для обработки XML / JSON.


Спасибо за все ваши ответы. Но может ли кто-нибудь просто ответить на мой первый вопрос? Зачем нам нужна спецификация для «архитектуры» ... может быть, кто-то может просто указать мне на любую другую архитектуру, которая предоставляет формальную спецификацию?
WinOrWin

Вы ищете больше причин, чем простота (несколько строк кода) и переносимость (развертывание в GlassFish, WebLogic, WebSphere, JBoss и т. Д.)? Вы можете разработать службу RESTful, используя спецификации более низкого уровня, такие как Servlets / JAXP / JDBC, но это обычно включает больше кода, чем спецификации более высокого уровня, такие как JAX-RS / JAXB / JPA.
bdoughan

Ответы:


72

Зачем использовать JAX-RS / Jersey?

Краткий ответ

Потому что это упрощает разработку сервисов RESTful.

Длинный ответ

JAX-RS - это стандарт, упрощающий создание службы RESTful, которую можно развернуть на любом сервере приложений Java: GlassFish, WebLogic, WebSphere, JBoss и т. Д.

JAX-RS является частью Java EE, и когда JAX-RS используется с другими технологиями Java EE, становится еще проще создать службу RESTful:

  • EJB - сеансовый компонент используется как реализация службы, а также обрабатывает семантику транзакции.
  • JAX-RS - используется для предоставления сеансового компонента как службы 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 не должна иметь состояния. Сеанс не сохраняется.
phi

Итак, JAX-RS более дружелюбен к XML, исходя из вашего ответа, что преобразование JSON доступно только с сервером GlassFish? Спасибо
pixel

Может ли кто-нибудь прокомментировать разницу с Springboot? Зачем использовать одно вместо другого? Спасибо
pixel

58

REST - это архитектура, которая по своей сути использует сервлеты.

Нет. REST - это архитектурный стиль, который может быть реализован с использованием сервлетов, но не использует их по своей сути и не имеет ничего общего с Java.

JAX-RS - это спецификация JSR, определяющая API Java для веб-служб RESTful.

Джерси - это конкретная реализация JAX-RS.

Что касается того, использовать ли Джерси или пытаться соответствовать спецификации JAX-RS, это как бы вам решать. Если это облегчит вашу работу - отлично! Если не тебя никто не заставляет.


12
+1 Дополнительное примечание: использование JAX-RS почти гарантированно будет намного проще, чем развертывание собственной реализации ReSTful с использованием сервлетов. В этом весь смысл.
Райан Стюарт,

@ Райан, Дон: В этом вся цель этого вопроса - нужен ли нам Джерси только для облегчения вышеупомянутых действий. И я знаю, что такое JAX-RS, я просто хочу знать, почему Java-разработчики предлагают отдельный API для этого ... PHP не предлагал ничего, и все же они, похоже, хорошо справляются.
WinOrWin

7
@WinOrWin: Мы тоже можем делать все в сборке, так зачем использовать Java? Все, что я могу сказать, это написать ReSTful API в обоих направлениях и решить, что вы хотите делать снова и снова.
Райан Стюарт,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.