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

12

Я относительно новый с точки зрения навыков веб-разработки на 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, но концептуально я еще не там (и мой проект будет использоваться в частной сети, поэтому безопасность на данном этапе не является приоритетом).

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

aCarella
источник

Ответы:

19

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

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 это так). Надеюсь, это даст вам некоторые идеи о том, как подойти.

Миньюн Ю
источник
1
Домен - это обычно слой, содержащий бизнес-логику. Домен обычно также называют слоем, содержащим сервисы. Доменные объекты не являются обычными объектами POJO. Доменный объект должен содержать бизнес-логику, такую ​​как проверка аргументов и так далее. Вероятно, было бы лучше переименовать слой в другое. Слой репозитория также довольно часто используется для передачи данных из нескольких источников в ваши доменные объекты.
Энди
Будут ли модули Service и Repository быть проектами Spring?
Гленн Ван Шил
1
@GlennVanSchil Нет, это не обязательно должны быть проекты Spring, так как при создании всего проекта слой repo / service будет включен в classpath. @AutowireБудет работать в качестве результата.
Миньюн Ю
@MinjunYu Спасибо за четкий ответ! Но вашему репо / сервису нужна пружина как maven-зависимость для аннотаций Service, Repository или Component, я прав?
Гленн Ван Шил
1
@GlennVanSchil Если вы поместите все зависимости Spring Maven в pom.xml родительского модуля, то нет необходимости добавлять какие-либо зависимости Spring в дочерние модули (модули репо / сервис). Это всего лишь один из способов макетирования нескольких модулей весной. Цель состоит в том, чтобы организовать ваш код. Если ваш проект не такой большой и не изменится в обозримом будущем, вы можете объединить домен, репо, сервис в одном модуле под названием «ядро». Это выглядит даже чище.
Миньюн Ю
2

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

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

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

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

kiwiron
источник