REST API с использованием Spring

Spring Framework WebMVC позволяет разрабатывать не только классические веб-приложения, но и реализовывать REST API. В этой статье я опишу процесс разработки REST API простого проекта на Java с использованием Spring Boot и Spring Framework.

Читать далее REST API с использованием Spring

Ускоряем Spring Boot: Автоконфигурации

Автоконфигурации в Spring Boot содержат большое количество заранее сконфигурированных компонентов, которые вы можете использовать либо без дополнительного конфигурирования, либо с указанием минимальных настроек вроде информации об адресах используемых сервисов, именах пользователей и паролях.

Читать далее Ускоряем Spring Boot: Автоконфигурации

Spring Framework: Functional Bean Registration

Functional bean registration is a feature that was added to Spring Framework 5. This feature allows to create and register beans in the application context without use of reflection API and also can boost up application startup time.

Читать далее Spring Framework: Functional Bean Registration

Spring Framework: Функциональная регистрация компонентов

В Spring Framework 5 была добавлена возможность функциональной регистрации компонентов (бинов) в контексте приложения.

Читать далее Spring Framework: Функциональная регистрация компонентов

XML-конфигурация Bean Validation

Компоненты Bean Validation могут быть сконфигурированы при помощи XML-файлов. Такой подход может быть удобен, когда требуется добавить валидацию классов, недоступных для изменения, либо в тех случаях, когда хочется избежать появления сторонних зависимостей в коде. Основной XML-файл конфигурации — META-INF/validation.xml, в нём находятся основные настройки Bean Validation.

Читать далее XML-конфигурация Bean Validation

Валидация данных при помощи Bean Validation API

Для валидации данных в Java EE существует Bean Validation. Первая версия данного набора API была специфицирована в JSR-303 и опубликована как часть Java EE 6. Текущая версия — 2.0, является частью Java EE 8 и описана в JSR-380. Эталонной реализацией Bean Validation является Hibernate Validator. Bean Validation может использоваться не только в классических приложениях на основе Java EE, но и в приложениях на основе Spring, и даже в приложениях, не имеющих отношения к Java EE.

Читать далее Валидация данных при помощи Bean Validation API

SOLID на практике — Принцип подстановки Барбары Лисков

Принцип подстановки [Барбары] Лисков (Liskov Substitution PrincipleLSP, буква L в аббревиатуре SOLID), сформулирован Барбарой Лисков в 1987 году и звучит следующим образом:

Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

Упрощенное описание этого принципа предложил Роберт Мартин:

Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

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

Читать далее SOLID на практике — Принцип подстановки Барбары Лисков

SOLID на практике — принцип инверсии зависимостей

Принцип инверсии зависимостей (Dependency Inversion PrincipleDIP, буква D в аббревиатуре SOLID), описанный Робертом Мартином, состоит из двух постулатов:

  • Высокоуровневые модули не должны зависеть от низкоуровневых; и те и другие должны зависеть от абстракций
  • Абстракции не должны зависеть от деталей, детали должны зависеть от абстракций

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

  • Взаимодействие между классами должно быть реализовано через интерфейсы или абстрактные классы
  • Типами всех членов классов должны быть интерфейсы или абстрактные классы
  • Классы, являющиеся конечными реализациями не должны расширяться (или должны быть финальными)
  • Аналогично методы не должны перекрываться при наследовании (или быть финальными)

Читать далее SOLID на практике — принцип инверсии зависимостей

Spring Security OAuth 2.0 и Apereo CAS

Фреймворк Spring Security позволяет реализовать авторизацию в приложении при помощи протокола OAuth 2.0. Провайдерами авторизации могут быть как общедоступные сервисы, вроде Google, Facebook или GitHub, так и персональные, реализованные, например, при помощи Apereo CAS.

Читать далее Spring Security OAuth 2.0 и Apereo CAS

SOLID на практике — принцип единственной ответственности

Принцип единственной ответственности (Single Responsibility Principle — SRP, буква S в аббревиатуре SOLID), описанный Робертом Мартином, гласит: «Класс должен иметь только одну причину для изменения».

Обратите внимание на следующий код:

В примере приведён метод сохранения изменений в записи типа Topic. Однако этот метод выполняет слишком много действий: валидацию полученных данных, поиск существующего объекта типа Topic, проверку прав доступа пользователя на этот объект, применение и сохранение изменений. И все эти действия могут меняться независимо друг от друга.

Следуя логике принципа единственной ответственности, нам следует выделить работу с источником данных, валидацию и проверку прав доступа, как минимум, в отдельные методы, а наиболее правильно — в отдельные классы.

Выделение логики в отдельные методы

В первом варианте мы разделим логику между методами класса TopicService. Кроме этого данные, получаемые методом update, логично будет инкапсулировать в одном классе:

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

Теперь этот код на уровне методов соответствует принципу единственной ответственности, чего не скажешь о всём классе TopicService. Не смотря на то, что методы findOneById, save, checkAccess и validate скрыты от внешнего наблюдателя, класс всё равно выполняет много действий.

Однако даже при этом код уже более удобен для понимания, а так же пригоден для повторного использования.

Выделение логики в отдельные классы

При выделении логики валидации, проверки прав и работы с источниками данных в отдельные классы, код приложения станет ещё удобнее и понятнее.

Таким образом мы получим класс, работающий с источником данных:

Класс, выполняющий валидацию UpdateTopicAction:

Класс, проверяющий доступ пользователя к объекту Topic:

Итоговый вид нашего сервиса будет следующим:

Таким образом мы на практике применили принцип единой ответственности.