RestAPI + Java+spring. Часть 4— создаем подобие документации. Controllers

4 min readMay 30, 2021

Разбор логики: по которой составляется API и все необходимые DTO

В первой статье мы разобрались что вообще будем делать.
Во второй части создали Spring Boot приложение и подключили к нему maven.
В третьей части мы подключили БД (H2) и создали класс для добавления объекта (Entity)

В этой статье мы разберемся, какие конечные точки у нас должны присутствовать в приложении, что мы принимаем и что мы отдаем фронту.

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

получение списка всех товаров, которые есть на складе
получение данных о конкретном товаре (по его идентификационному коду)
количество товаров определенного вида на складе
добавление товара на склад
удаление товара со склада

каждый пункт функционала — это отдельный API. Что касается проверки, в каком состоянии находится приложение мы можем по адресу -

http://localhost:8080/actuator/health

если все ОК, мы должны увидеть такую надпись

API

Первая точка входа в приложение — это создание продукта. Это POST request, который должен принять объект для сохранения, и вернуть этот же сохраненный объект.

Кроме этого, у нас будут GET запросы:
получение данных о конкретном товаре — возвращает товар
количество товаров определенного вида на складе — возвращает товар и его количество
получение списка всех товаров, которые есть на складе — возвращает список всех товаров на складе.

И DELETE API который удалит товар из базы данных. По правилам хорошего тона, при запросе на удаление мы возвращаем объект, который был удален.

Кроме этого, мы должны возвращать код ответа на каждый запрос.

201 — Created — означает, что все ОК, и объект был создан
404 — Not Found
409 — Conflict — означает что клиент хочет добавить товар, который уже есть на складе (товар должен быть уникальным
410 — Gone — означает что сервер не может найти тот товар, который мы запрашиваем. Например — товар был удален.

Пишем код API

создаем новый класс ItemController в пакете controllers и ставим ему аннотацию @RestController

класс —

далее пишем конечную точку. метод будет называться createItem, принимать он будет ItemDto а возвращать ResponseEntity

это стартовый вариант метода. Дальше осталось добавить в него функциональность.

Создаем ItemDto — это класс объекта, который мы будем принимать и отдавать пользователю. Этот объект, по сути, отличается от объекта Item тем, что мы не хотим “светить” в интернете id товара. Поэтому в DTO мы его не добавим.
Создаем класс ItemDto в пакете dto, добавляем аннотации Lombook для создания обьекта, геттеры и сеттеры->

кроме этого, добавляем зависимости для валидатора. А именно —
— все поля объекта обязательны для заполнения

2. Теперь пришло время заниматься логикой. Логика реализуется в пакете service в классе ItemServiceImpl (но перед этим необходимо создать интерфейс ItemService).
Для того, что бы контроллер “увидел” сервис, необходимо инжектировать класс ItemServiceImpl. Делается это при помощи аннотации @Autowired в контроллере, плюс сам инжектируемый класс должен был отмечен аннотацией @Service (т о мы создаем Bean нашего сервиса, и добавляем его в application.context спринга)

Таким образом контроллер выглядит