Зачем использовать фреймворк для сервисов RESTful в Java вместо ванильных сервлетов? - PullRequest
22 голосов
/ 20 января 2012

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

  • www.example.com / изображения
  • www.example.com / изображения / ID / Num
  • www.example.com / изображения / теги / Num
  • www.example.com / изображения / теги / Num / Num / Num

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

По сути, я спрашиваю ... Какова ценность использования среды Java RESTful? Разве это не добавит много сложностей в реализации для простой проблемы?

РЕДАКТИРОВАТЬ: Этот код Джерси обрабатывается очень аккуратно, и каждый должен знать, как сделать это в форме сервлета, если они ищут библиотеки, чтобы сделать это для них.

@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, поэтому возвращается простой текст, нужна ли инфраструктура?

Ответы [ 4 ]

12 голосов
/ 20 января 2012

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

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

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

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

7 голосов
/ 20 января 2012

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

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

3 голосов
/ 20 января 2012

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

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

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

2 голосов
/ 20 января 2012

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

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

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

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