Сервлет против REST

Мне нужно создать 5 методов на стороне сервера, которые будут работать с двоичными данными. Удаленные клиенты - это апплет и JavaScript. Клиент отправит файлы на сервер, и сервер должен проанализировать эти файлы, а затем вернуть ответ как XML/JSON.

Итак, я смущен - хорошая практика использовать REST-сервис в этом случае? Или я должен использовать сервлет?

Мой коллега сказал мне:

"Создание REST-сервиса, которое будет использоваться только одним Приложением, не хорошо. REST должен быть создан только тогда, когда он будет использоваться многими приложениями. А также REST имеет некоторые недостатки над сервлетом: REST медленнее сервлета; сложнее писать потокобезопасный REST, чем сервлет"

Однако я вижу некоторые недостатки при использовании Servlet: мне нужно отправить имя функции, которую я хочу вызвать (например, в качестве дополнительного имени функции отправки параметров HTTP) а затем внутри метода doPost выполните следующие действия:

switch(functionName) {
 case "function1":
   function1(); 
   break;
 case "function2"
   function2(); 
   break;
//.... more `case` statements....

}

В случае REST я могу просто использовать разные URL-адреса для разных функций. Кроме того, в случае REST более удобно возвращать JSON/XML с сервера.

Спасибо.

Ответы

Ответ 1

Ну, Я бы не согласился с мнением ваших коллег, что нехорошо отдыхать, используемое только одним приложением, поскольку в будущем вы можете решить использовать разные приложения, используя один и тот же остаток api. Если бы я был вами, я бы выбрал чистый ОТДЫХ. Почему?

  • Если вы используете фреймворк для реализации отдыха (скажем apache cxf или jersey) вы получаете много вещей из коробки - вы пишете POJO, вы отдыхаете, вы получаете сериализацию и десериализацию, от и до того, чтобы сказать, что объект JSON из коробки (в конечном итоге вам нужно будет реализовать некоторые JsonProviders, но это не большое дело).

  • Интуитивно работать (если вы хорошо разработали свои API для отдыха).

  • Очень легко расходуется клиентами JavaScript (особенно если вы используете JQuery или что-то в этом роде)

Однако, это сильно зависит от того, что именно вы хотите сделать, если у вас есть сильная транзакционная логика, остальное может быть довольно сложным. Если вы только собираетесь делать POST-запросы (без использования других методов HTTP), вы можете использовать Servlet, так как вам не придется работать с дополнительными фреймворками и создавать больше зависимостей. Обратите внимание, что REST - это более или менее архитектурная концепция, и это не противоречит технологии Servlet, если вы достаточно упрямы, вы можете отдохнуть просто с сервлетами:-). Надеюсь, я помог.

Ответ 2

Здесь вы вводите в заблуждение две парадигмы:

  • REST - это "стиль" архитектуры программного обеспечения;
  • Сервлет - это серверная технология.

Вы можете, например, реализовать сервисы типа REST, используя Servlets.

Ответ 3

Я не вижу никаких проблем с использованием Джерси и создания службы REST. Я знаю, что я REST-taliban, но очень просто реализовать такую ​​архитектуру с помощью JAX-RS, поэтому... почему бы и нет?

Ваши коллеги говорят: "REST должен быть создан только тогда, когда он будет использоваться многими приложениями", но я не вижу, как это может быть правдой. Почему я не могу создать службу REST для одного приложения?

Ответ 4

Во-первых, вы говорите в терминах двух разных парадигм. Это своего рода яблоки и апельсины.

REST - это стиль службы, который использует операции HTTP (GET, PUT и т.д.) для чтения и записи состояния ресурсов. Подумайте о ресурсах как "существительные" и "вещи".

Servlet, с другой стороны, представляет собой спецификацию программного обеспечения, первоначально предоставленную Sun Microsystems для подключения HTTP-запросов к настраиваемому Java-коду. Сервлеты часто говорят в терминах вызовов метода: "глаголы" и "действия".

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

Ответ 5

В зависимости от вашей версии контейнера Джерси (или любая другая реализация JAX-RS) все равно будет использовать сервлет для отправки запросов соответствующему обработчику.

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

Кроме того, не путайте XML или JSON с REST. Вы получите их бесплатно в большинстве (если не во всех) реализациях JAX-RS, но эти реализации по-прежнему делегируют объединение контента другим библиотекам (например, JAXB).

Ответ 6

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

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