Сервлеты против Бобов

Question

Мне нужен совет от опытных разработчиков относительно программной архитектуры проекта.

Необходимо предоставить интерфейс REST для API, чтобы клиент мог: 1) аутентифицировать себя (это также включает в себя обработку создания учетной записи) 2) Выполните запросы get / add / update / delete () на ресурсы (например, сохраните описание новой книги [title + author ..])

Нет необходимости (пока) в WSDL или других сложных вещах. Я бы сказал, что предпочитаю избегать WSDL, если это возможно, поскольку я определенно не буду его использовать Это не будет использоваться для веб-сайта, только для прямого использования API.

Я прочитал много вещей, но мне нужен четкий статус по следующим вопросам: - Вы бы использовали сервлеты или бобы? - Аутентификация - это хорошая идея? Какой самый лучший и простой способ обработки сеансов?

Я ищу самый простой способ, так как мои знания J2EE в настоящее время довольно низкие.

Спасибо за ваше время!

Answer 1

Если клиенты будут использовать веб-интерфейс для доступа к вашему сайту, лучше использовать систему на основе сеансов.Если это просто сервисный API-интерфейс, используемый программами, то используйте HTTP-аутентификацию.

Если вы собираетесь использовать сервисный API-интерфейс, вам, вероятно, лучше всего будет воспользоваться одной из сред RESTy, таких как JAX.-RS.Вы можете использовать это для реального веб-сайта, но обычно он не используется таким образом (поэтому примеры не соответствуют домену).

Если вы работаете с веб-сайтом, посмотрите на один изкаркасы действий, такие как Stripes или Struts 2. Они позволят вам связывать URL-адреса RESTy, но они также отлично подходят для веб-сайтов.

Для любого из них было бы лучше иметь базовое пониманиеСервлеты, в частности HTTP, рабочий процесс, различия между перенаправлениями и пересылкой и т. Д., Поскольку эти платформы используют базовую модель сервлетов.

Все это можно легко сделать с помощью необработанных сервлетов, структуры просто упрощают работу, ии JAX-RS, и Stripes / Struts 2 имеют довольно слабый удар, чтобы начать работу.

Answer 2

аутентификация себя (это также включает в себя обработку создания учетной записи)

Сервлеты имеют встроенные функции безопасности, а также несколько библиотек (Spring security, Apache Shiro).

Нет необходимости (пока) в WSDL или других сложных вещах.

WSDL чаще всего используется для описания веб-службы SOAP.

Вы бы использовали сервлеты или бобы? - для обработки аутентификации

Вы имеете в виду корпоративные Java-бины? Они вам не помогут, вам все еще нужно что-то для обработки HTTP-запросов - когда сервлеты вступают в игру. Но вам, вероятно, захочется иметь что-то для реализации реальной бизнес-логики - сервлеты - это всего лишь шлюз , там логика не реализуется.

Технически вы можете представить EJB через SOAP (но вы хотели REST) ​​или использовать JAX-RS (часть стека Java EE), но, очевидно, он использует сервлеты внизу.

собирается сохранить состояние, хорошая идея

В принципе - REST не имеет состояния, разговорного состояния нет. Однако аутентификация по каждому запросу может стоить слишком дорого. Таким образом, в конце HTTP-сеансов (которые легко обрабатываются с помощью сервлетов) вы как минимум сохраните JSESSIONID.

Answer 3

Одним словом? И то и другое. Вам нужны как сервлеты, так и bean-компоненты на основе интерфейса POJO, но нельзя делать одно и то же.

Если вы хотите REST, вы будете использовать сервлеты. Это слушатели HTTP в Java EE, а REST основан на HTTP.

С учетом вышесказанного, я бы порекомендовал использовать основанные на интерфейсе POJO для реализации кода, который выполняет всю работу. Это облегчит тестирование и изменение вашего кода.

REST - один из многих вариантов развертывания. Если вы придерживаетесь основанных на интерфейсе POJO, вы сможете изменить стратегию развертывания, просто используя другую оболочку для bean-компонента.

Уровень REST не должен делать ничего, кроме аутентификации и авторизации, привязки и проверки. Позвольте ему отложить боб POJO для выполнения работы.

Сервлеты обрабатывают сеансы с перезаписью URL или куки. Используйте то, что они вам дают.

Но службы REST должны быть без гражданства; между вызовами нет ни одного сеанса, ни состояния.

Вы можете использовать Фильтр для проверки подлинности перед выполнением вызова. Это сквозной путь. Думайте о фильтрах как об аспектах HTTP.