Подтвердить что ты не робот

Зачем использовать фреймворк для сервисов RESTful в Java вместо валинных сервлетов

Я знаю, что есть несколько вопросов относительно библиотек, которые вы можете использовать для выполнения RESTful-сервисов на Java, но какова их ценность при использовании ванильных реализаций. Я имею в виду, если бы я хотел создать структуру URL, описанную Wim

  • www.example.com/images
  • www.example.com/images/id/num
  • www.example.com/images/tag/num
  • www.example.com/images/tag/num/num/num

Не будет ли проще (для будущих разработчиков) и быстрее (внедрять и учиться) сопоставлять шаблон/изображения url с сервлетом и иметь строку или две, которая анализирует URL-адрес для параметров вместо обучения, реализации и настраивая одну из этих библиотек, чтобы сделать это для вас.

По сути, я задаю вопрос... Какова ценность использования RESTful Java framework? Не будет ли это сложной задачей при реализации для простой задачи?

EDIT: этот код Джерси обрабатывается очень аккуратно, и каждый должен знать, как это сделать в форме сервлета, если они ищут библиотеки, чтобы сделать это для них.

@Path("/helloworld")
public class HelloWorldResource {

    // The Java method will process HTTP GET requests
    @GET
    // The Java method will produce content identified by the MIME Media
    // type "text/plain"
    @Produces("text/plain")
    public String helloWorld() {
        // Return some cliched textual content
        return "Hello World";
    }
}

Если все, что вы собираетесь делать, это "служба", которая возвращает текст, который управляется параметрами URL, поэтому возвращается обычный текст, необходима ли структура?

4b9b3361

Ответ 1

Не было бы проще (для будущих разработчиков) и быстрее (внедрять и учиться) сопоставлять шаблон url /images сервлету и иметь строку или две, которая анализирует URL-адрес для параметров вместо обучения, реализуя и настроить одну из этих библиотек, чтобы сделать это за вас.
...

Легче? Это, конечно, не проще писать - вам нужно сделать все извлечение пути самостоятельно и всю обработку метода и все согласования типа содержимого (в обоих направлениях) и всю обработку файлов cookie, а также десериализацию/сериализацию объектов thunks и... ну, множество низкоуровневых материалов, которые все нуждаются в тестировании и отладке, - или их проще поддерживать, поскольку интерфейс JAX-RS позволяет вам работать на уровне ресурсов (естественная характеристика веб-приложений RESTful) вместо запросов; с большим опытом, обслуживание легче всего, когда разрыв между концептуальной моделью и реализацией является наименьшим. Это также не так быстро реализовать (потому что низкоуровневые реализации JAX-RS уже протестированы и отлажены для вас, меньше для вас), а стоимость обучения невелика, так как это в основном декларативный API с очень небольшим количеством сюрпризов.

ОК, эти преимущества могут показаться не такими уж важными, если вы имеете дело только с простыми веб-приложениями. В конце концов, вы можете взломать что-то в очень короткое время и положить результирующий вырез онлайн. Затем вам придется молиться, чтобы вы поняли это без существенных неожиданных возможностей для эксплойтов или атак типа "отказ в обслуживании". И программисты по обслуживанию должны будут понять, что эти регулярные выражения, которые вы использовали в коде, делают (удачи с этим!) При добавлении небольших функций или исправлении ошибок. Но по мере того, как webapp становится больше, преимущество наличия проверенной библиотеки для обработки всего низкоуровневого материала действительно выигрывает.

(Прежде чем вы спросите, некоторые из упомянутых вами библиотек будут легко устанавливать себя как сервлеты, это позволяет вашему коду просто описать бизнес-логику сервлета и объявить, как сопоставление с проводкой выполняется в абстрактных терминах. легче.)

Ответ 2

JAX-RS - очень хорошо разработанный API, который упрощает сопоставление HTTP-запросов с методами, извлечение параметров из различных частей HTTP-запроса, ведение переговоров по содержимому и многие другие задачи низкого уровня.

Использование JAX-RS, в основном через Apache CXF, в течение примерно двух лет, я всегда предпочитаю его поверх простых сервлетов.

Ответ 3

Рамки используются для упрощения задачи. Я согласен, что мы можем сделать то же самое, реализуя сервлеты, а затем проанализируем URL-адрес, а затем реализуем основную логику.

Bu, если вы используете фреймворк, например, трикотаж, тогда вам не нужно беспокоиться об этих шаблонах синтаксического анализа и других подобных задачах. Класс ServletContainer позаботится об этом (разбор URL-адреса в этом методе обслуживания), и есть много других классов, которые облегчат вашу задачу.

И еще одно: мы принимаем только один сценарий (совпадающие шаблоны), но когда наши требования будут расти, тот же код, написанный нашими сервлетами, станет более сложным и сложным.

Ответ 4

В этом случае я бы пошел с использованием Джерси или библиотеки, если он делает следующее (добавляет достаточно значения):

  • Конфигурация для URL-адреса является полностью автономной в одном файле с исходным текстом
  • нет скрытых файлов конфигурации или слишком подробных конфигураций (например, web.xml)
  • параметры хорошо сопоставляются с сильно типизированными переменными (например, использование аннотаций)
  • не запутано, чтобы перейти к значениям параметров (например, RESTlet)
  • Накладные расходы на запуск библиотеки низки (у меня были плохие впечатления с решениями отражения в других библиотеках).
  • он хорошо документирован
  • он хорошо принят

В таком сценарии я обнаружил, что использование библиотеки добавит ценность моему проекту для усилий, необходимых для его использования. Джерси, похоже, удовлетворяет требованиям вполне адекватно, хотя я еще не дал другим рамкам достаточно исследований.