7 причин, по которым я не использую JAX-RS в веб-приложениях Spring Boot

JAX-RS существует уже большую часть десятилетия, и я потратил немалую часть своей карьеры, работая с ним. Я даже создал несколько собственных надстроек JAX-RS, которые мои коллеги неофициально называли «JoeRS».

Но я пошел дальше. Теперь, когда я последовательно использую Spring Boot в качестве основы для своих приложений, я обнаружил, что с Spring MVC работать проще, чем с JAX-RS. Это не потому, что JAX-RS плохой или потому что Spring Boot не хватает сильной поддержки JAX-RS. На самом деле, я считаю, что команда Spring Boot сделала все возможное, чтобы обеспечить работу JAX-RS в Spring Boot. Несмотря на это, вот семь причин, по которым я не обязан продолжать использовать JAX-RS в приложениях Spring Boot.

1. Spring MVC приводит к более «стандартным» приложениям (как ни странно)

Позвольте мне перефразировать разговор, который я имел с коллегой-архитектором по недавнему проекту Spring Boot.

• «Наш утвержденный технический стек требует, чтобы приложения в стиле REST использовали JAX-RS».
• «Какая версия спецификации JAX-RS?»
• «2,1»
• «Я удивлен, что наш стек технологий предприятия настолько актуален. Какая реализация одобрена?»
• «Ничего особенного, если он совместим с JAX-RS 2.1. Я предлагаю перейти на RESTEasy».
• «Последний стабильный выпуск RESTEasy поддерживает только JAX-RS 2.0. Кроме того,  start.spring.io  не предлагает стартер RESTEasy, только Jersey и Apache CXF».
• «CXF? Я не знал, что это была реализация JAX-RS. Что ж, давайте поговорим о Джерси. В конце концов, это эталонная реализация, поэтому она должна поддерживать JAX-RS 2.1».
• «Да, но самая последняя версия Spring Boot 1.5 Jersey Starter находится на Jersey 2.25, а это только JAX-RS 2.0.1. Может быть, мы могли бы сделать исключение POM, чтобы добавить Jersey 2.26 и JAX-RS 2.1».
• «Это раздражает. Может быть, нам стоит пока придерживаться JAX-RS 2.0 и надеяться, что скоро выйдет более новая версия Spring Boot, которая обновит Джерси до 2.26. Кроме того, что есть в JAX-RS 2.1, чего нет в 2.0?»
• «Я не знаю — скорее всего, ничего такого, что могло бы повлиять на наше приложение».

К этому моменту мы потратили столько же времени на обсуждение спецификационных версий и реализаций, сколько и написания наших начальных Spring MVC Rest Controllers. И для чего? Таким образом, мы могли бы использовать некоторую «стандартную» технологию, которая предотвращает нас от привязки к конкретному поставщику и / или обеспечивает большую согласованность между разрабатываемыми приложениями?

Стандарты имеют свое место, как в строительстве и сантехнике, но я обнаружил, что  «стандарты» JavaEE / J2EE / EE4J / what -the-new-name-be-be будут довольно неплотными. Я никогда не видел  .ear порт без проблем из одного контейнера приложения в другой. Также я был на проекте , где я мог бы, скажем, заменить   org.jboss.resteasy:resteasy-jaxrs:3.1.4.Final с  org.glassfish.jersey.core:jersey-server:2.25.1 (две реализации JAX-RS 2.0) в POM, перекомпилируйте и запустите приложение без проблем. Я знаю, как настроить глобальные ресурсы JNDI в Tomcat; Я не знаю, как это сделать в Jetty, несмотря на то, что они оба реализуют спецификацию сервлета. В конечном счете, технология реализации спецификации отчетливо проявляется в приложении, вводя некоторую степень связи с конкретной реализацией, уменьшая предполагаемое значение спецификации как «стандарта».

В частности, для JAX-RS разработчик приложения Spring Boot должен сначала решить, использовать ли доступный стартер Spring Boot JAX-RS или вручную интегрировать альтернативную реализацию, такую ​​как RESTEasy или Restlet. Для тех, кто выбирает стартер, они должны выбрать между Apache CXF и Джерси. И как только реализация выбрана, разработчик должен решить, как конкретно интегрировать ее в приложение.

Следовательно, приложения Spring Boot, использующие JAX-RS, могут быть более разнообразными по своим вариантам реализации, интеграции и конфигурации, чем приложения, которые просто используют Spring MVC. Выбор использования Spring MVC избавляет разработчиков от обдумывания этих конкретных решений JAX-RS.

2. Мне не нужно больше думать о версиях

Одной из величайших функций Spring Boot (помимо  настраиваемых баннеров , конечно) является   spring-boot-dependenciesPOM , который включается в POM благодаря  наследованию от spring-boot-starter-parent . Эта отдельная зависимость управляет версиями многих различных библиотек Java, API и плагинов Maven, освобождая меня от бремени знания, например, включаю ли я последнюю версию Lombok или плагин Surefire.

Spring Boot позволяет мне более блаженно не знать о конкретных версиях зависимостей, которые я использую. Напротив, спецификация JavaEE, такая как JAX-RS, по существу требует знания версии: версия API JAX-RS, которую я хочу использовать, и версия библиотеки реализации, предназначенная для этой версии, все для того, чтобы получить возможности, уже доступные в Сама весна.

Конечно, вы можете добавить стартовую версию Jersey Spring Boot и быть в блаженном неведении относительно конкретной версии Jersey и API JAX-RS в игре, но это, на мой взгляд, уменьшает «стандартный» аргумент для использования JAX-RS. Если ваш основной аргумент в пользу JAX-RS — «Я просто более знаком с ним», рассмотрите остальные причины, по которым я предпочитаю Spring MVC.

3. Мне не нужно думать о нескольких контейнерах IoC

Кто отвечает за управление жизненным циклом классов ресурсов JAX-RS в приложении Spring Boot? Весна? Реализация JAX-RS? Обе? По-разному.

При условии, что я использую только JAX-RS @Context и различные  @***Param аннотации для ввода информации из запроса, реализация JAX-RS может управлять жизненным циклом класса без необходимости использования Spring. Однако, как только мне нужно внедрить другие управляемые зависимости, нужно что-то более тяжелое. JAX-RS 2 предоставляет подробную информацию о том, как контейнер CDI должен работать с классами ресурсов JAX-RS. Однако, так как мы используем Spring, кажется излишним добавлять некоторую реализацию CDI к миксу.

Чтобы Spring управлял жизненным циклом класса ресурсов, я могу пометить свои классы ресурсов  @Component аннотацией. Но я должен помнить о масштабах. По умолчанию классы ресурсов JAX-RS находятся в области запросов, а компоненты Spring — в приложениях. Рассмотрим следующий класс ресурсов:

@Component
@Path("/greeting")
public class GreetingResource {

    @QueryParam("n")
    private String name;

    @GET
    @Produces("text/plain")
    public String greet() {
        return "Hello, " + Optional.ofNullable(name).orElse("world") + "!";
    }
 }

@Component
public class JerseyConfig extends ResourceConfig {
    public JerseyConfig() {
        register(Every.class);
        register(Single.class);
        register(ResourceClass.class);
        register(Must.class);
        register(Be.class);
        register(Registered.class);
    }
}