Структура сервиса RESTful с Java Spring для начинающих

Я относительно новый с точки зрения навыков веб-разработки на Java. У меня есть проект, который, я думаю, мог бы стать хорошим кандидатом на службу RESTful из того, что я мало понимаю об API. Я пытаюсь вникнуть в детали того, как это должно быть структурировано, но на самом деле нигде не разбираюсь в поиске в Google и не читаю материал, который у меня уже есть. Я надеюсь, что этот пост приведет к некоторой проверке и / или перенаправлению с точки зрения моих знаний и предположений по этой теме.

Мое текущее предположение состоит в том, что моя служба RESTful будет иметь следующую структуру:

• База данных (SQL).
• ORM (я использую относительно непопулярную ORM, называемую CPO, но большинство людей просто заменит ее на Hibernate).
• Класс менеджера Java с методами, которые общаются с ORM для получения данных
• Класс / классы контроллера Java, которые обрабатывают сопоставление запросов и используют @ResponseBodyдля направления / обработки URL-адреса и действия по обработке данных с помощью HTTP-глаголов ( http://mysite.com/computers/dell может быть GETзапросом со словом «dell») в URL-адресе, являющемся параметром, который будет возвращать JSON-массив информации о компьютерах dell).
• Этот сервис должен быть выполнен с помощью Spring Boot или каким-то образом иметь возможность работать отдельно и быть независимым от любого другого приложения.

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

Скажем, у меня есть веб-приложение. Допустим, я создаю веб-приложение об информации о компьютерном оборудовании и использую Spring для создания этого веб-приложения. Вот мои предположения:

• Я бы имел несколько представлений в виде JSP с JSP, включающими HTML, CSS и JavaScript. JavaScript будет обрабатывать вызовы AJAX для контроллера этого приложения по мере необходимости (ниже).
• Это веб - приложение также будет иметь свой собственный контроллер для обработки запросов URL в приложении и маршрутизации, и контроллер будет затем использовать, скажем, ModelAndViewобъект или что - то вдоль этих линий , чтобы «поговорить с» контроллером успокоительных сервиса, получить то , что данные передается , передать эти данные обратно в представление (Javascript, JSP и т. д.) для отображения.

Я на правильном пути, здесь? Я понимаю, что есть также аспект аутентификации для сервисов RESTful, но концептуально я еще не там (и мой проект будет использоваться в частной сети, поэтому безопасность на данном этапе не является приоритетом).

Любое понимание, критика, знание, обратная связь или разъяснение очень ценится.

Вот один из моих любимых примеров структуры вашего весеннего отдыха.

1. Разделение слоев, каждый слой представляет собой отдельный модуль / проект

• REST API
  • Упакован как war (Может быть, jar, если вы используете весеннюю загрузку со встроенным сервером. Spring boot doc четко объясняет, как развернуть так называемый uber jar . Это смертельно просто.)
  • У него есть контроллеры отдыха, которые обрабатывают запрос / ответы
  • зависит от сервисного модуля ниже
• обслуживание
  • Упаковано как банка
  • Абстракции бизнес-логики, этот уровень не знает, как взаимодействовать с источником данных.
  • Это будет автоматически подключено в контроллерах покоя
  • Зависит от модуля DAO / Repository ниже
• DAO / Repository
  • Упаковано как банка
  • Общается с источником данных напрямую, имеет операции, обычно известные как CRUD. Это может быть простой jdbc, JPA или даже доступ к файлу.
  • Зависит от модуля домена ниже
• Домен
  • Упаковано как банка
  • У него есть ваши доменные модели, обычно классы POJO. Если вы используете ORM, они являются сущностями ORM.
  • Он также может иметь DTO (Data Transfer Object), который все еще находится в стадии обсуждения. Используйте это или нет, это ваш звонок.
• Вы можете добавить больше модулей, таких как утилита, сторонняя интеграция и т. Д., Но вышеперечисленное настоятельно рекомендуется иметь.

2. Инструменты управления сборкой / зависимостями (ИМХО очень нужно)

Их много, поиск в гугле покажет вам. Мне лично нравится Maven с Spring. Это просто работает для вышеуказанной структуры проекта.
Также обратите внимание, что если вы используете maven, существует родительский модуль, который объединяет все модули, описанные в разделе 1. Все модули маркированного списка также соответствуют модулям maven.

3. Мысли о вашем конкретном проекте

Поскольку вы используете REST, я настоятельно рекомендую вам НЕ использовать JSP для просмотра. Вы можете использовать обычный HTML5 + Javascript или какой-либо популярный фреймворк, например AngularJS.
Если вы настаиваете на использовании JSP, вам нужно будет ввести еще одну войну (веб-приложение) с контроллерами и JSP. Контроллер получит данные (обычно в формате Json / xml), а затем проанализирует их для ваших моделей (POJO), чтобы ваш JSP мог получить их от вашего контроллера и выполнить отображение. Публикация данных из JSP производится в обратном порядке, я здесь опущен.

Это далеко не полный справочник, так как эта тема довольно обширна и сильно зависит от ваших конкретных требований, но включенных здесь терминов достаточно для проведения дополнительных исследований (Google это так). Надеюсь, это даст вам некоторые идеи о том, как подойти.

Соглашаясь с большинством ответов от @ Minjun.Y, я думаю, что я бы использовал немного другой подход к слою REST и веб-страниц. Из моего прочтения вашего вопроса я думаю, что вы хотите представить как веб-интерфейс, так и интерфейс REST для внешнего мира. Чтение мало чего можно получить, читая POJO из базы данных, превращая данные в JSON, а затем обратно в POJO для использования JSP.

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

Кроме того, я не большой поклонник модулей Maven. Наш Java-магазин будет реализовывать ваш проект так, чтобы сделать регулярные выпуски сервисного уровня, а затем сделать уровни представления зависимыми от последнего выпуска. Здесь есть место для обсуждения, но это, безусловно, работает для нас. Мы бы имели веб-интерфейс и REST-интерфейсы как отдельные проекты Maven, поскольку они обычно находятся в разных файлах .war и, следовательно, требуют отдельного развертывания.

Кстати, я бы подчеркнул необходимость в ускорении использования инструментов управления сборкой и зависимостями. Как только ваш проект вырастет до любого разумного размера, они вам понадобятся. Бесплатные инструменты, такие как Maven, Jenkins и Nexus, упрощают управление релизами.