Spring MVC и REST

Путь запроса через Spring MVC

Запрос идёт по цепочке. Веб-слой тут называется Spring MVC (model-view-controller, модель-представление-контроллер) - по классическому разделению на данные, их отображение и обработчик. Сначала запрос попадает в DispatcherServlet - единую входную дверь, через которую проходит всё. Дальше HandlerMapping подбирает метод-обработчик по пути и типу запроса - GET, POST и остальным. Потом резолверы аргументов наполняют параметры: @PathVariable берёт кусок из самого пути, @RequestParam - из строки запроса после вопросительного знака, @RequestBody - из тела. Потом выполняется твой метод, и HttpMessageConverter превращает возвращённый объект в JSON.

@RestController - это сокращение для @Controller плюс @ResponseBody: возвращённое значение становится телом ответа, без всякого слоя шаблонов. Маршруты вешаются аннотациями @GetMapping, @PostMapping и родственными.

// Путать @PathVariable и @RequestParam дорого, и коды разные. Я проверил на одном приложении: обязательный параметр запроса не передан - ответ 400; обращение по пути без нужного сегмента - 404. Ещё грабли из той же области: если проект собран без флага компилятора -parameters, Spring не знает имён параметров и падает с сообщением «Name for argument of type [java.lang.String] not specified». Сборки Spring Boot этот флаг ставят сами, ручные - нет.

DispatcherServlet

единая входная дверь: направляет запрос нужному методу

HttpMessageConverter

превращает тело запроса в объект и объект ответа в JSON

Валидация и единый формат ошибок

Вернёмся к замеру. Ограничения описываются прямо на полях объекта: @NotBlank, @Email, @Min и другие из стандарта проверки бинов. Но выполняться они начинают, только когда аргумент помечен @Valid. Тогда нарушение бросает MethodArgumentNotValidException, и клиент получает 400 с разбором по полям - у меня вышло «age: must be greater than or equal to 18; email: must be a well-formed email address; name: must not be blank». Все три нарушения сразу, без единого написанного if.

Без @Valid тот же запрос прошёл с кодом 200, и объект с пустым именем уехал дальше в приложение. Дыра тихая: ошибок нет, логи чистые, аннотации на месте - заметить можно только тестом.

Обрабатывают ошибки централизованно: класс с @RestControllerAdvice собирает обработчики @ExceptionHandler и отдаёт единый формат на всё приложение. Так у клиента один вид ошибки везде, вместо try-catch в каждом контроллере.

record UserDto(@NotBlank String name, @Email String email, @Min(18) int age) {}

@PostMapping("/checked")   UserDto a(@Valid @RequestBody UserDto d) { return d; }
@PostMapping("/unchecked") UserDto b(@RequestBody UserDto d)        { return d; }

// одно и то же кривое тело:
//   с @Valid  -> 400  age: must be greater than or equal to 18; email: ...; name: ...
//   без @Valid -> 200  {"name":"","email":"не-почта","age":15}

@Valid

включает проверку объекта по ограничениям на его полях

@RestControllerAdvice

общие обработчики исключений: единый формат ошибки на всё приложение

Почему наружу отдают не объект базы

Entity - это класс, отображённый на таблицу базы: его полями управляет ORM. DTO (data transfer object) - отдельный объект под передачу данных, в нём ровно те поля, которые нужны клиенту. На границе приложения отдают именно DTO, и вот почему.

Первое - ленивые связи. ORM (object-relational mapping, отображение объектов на таблицы) подтягивает связанные объекты не сразу, а при первом обращении к ним, и делает это в рамках открытой сессии - соединения с базой, которое живёт на время операции. Если превращение объекта в JSON происходит уже после закрытия сессии, прилетает LazyInitializationException. Вариант похуже - связи всё-таки подгрузятся, и один запрос вытянет пол-базы. Второе - утечка: наружу уедут все поля, включая служебные флаги и то, чего клиенту знать не надо. Третье - связность: форма ответа окажется прибита к схеме таблицы, и любая миграция базы сломает контракт для клиентов.

// Контроллеру можно разобрать запрос, проверить его, преобразовать и позвать сервис. Бизнес-логику в него не кладут: её не переиспользовать и не покрыть быстрым тестом. Коды ответов стоит выбирать осмысленно: 201 с заголовком Location на создание, 204 на удаление, 400, 404 и 409 по смыслу. А проверять контроллеры удобно через MockMvc - он гоняет запросы через всю цепочку Spring MVC без запуска настоящего сервера, ровно так сняты замеры этого урока.

entity / DTO

объект, отображённый на таблицу / объект для передачи данных наружу

MockMvc

вызов контроллеров в тесте без поднятия настоящего сервера

Как отвечать: «Почему нельзя отдавать entity из контроллера?»

Три причины, и все кусаются на проде. Первая - ленивые связи: сериализация в JSON происходит уже после того, как сессия базы закрыта, и обращение к недогруженной связи даёт LazyInitializationException, а если сессия ещё открыта, то один запрос может жадно вытянуть пол-базы. Вторая - утечка данных: наружу уходят все поля, включая внутренние флаги и связи, которые клиенту знать не положено. Третья - связность: форма JSON намертво прибивается к схеме таблицы, и любая миграция базы ломает контракт API. Поэтому на границе я всегда преобразую entity в DTO - ровно те поля, что нужны клиенту, и контракт живёт отдельно от хранилища. Заодно это защищает от обратной проблемы: клиент не сможет прислать поле, которое ему менять нельзя.

Почему это сильный ответ: три разноплановые причины - техническая, безопасность и архитектурная связность, - плюс замечание про обратное направление, о котором обычно забывают.

На чём валят

• −Забыть @Valid. Ограничения на полях есть, проверки нет: у меня кривое тело прошло с кодом 200.
• −Отдавать entity наружу. Ленивые связи, лишние поля и контракт, приколоченный к схеме базы.
• −Путать @PathVariable и @RequestParam. Пропущенный обязательный параметр запроса даёт 400, неверный путь - 404.
• −Ловить исключение в контроллере и возвращать 200 с телом об ошибке. Клиент считает, что всё прошло успешно.
• −Бизнес-логика прямо в контроллере. Её не переиспользовать в другом входе и не покрыть тестом без веб-слоя.