Используются ли в Spring interceptors для обработки запросов

Что проверяют

Знаете ли вы, какие точки перехвата есть в Spring и чем они отличаются. Обычно за вопросом следует «а фильтр или перехватчик, и почему».

Как отвечать

Да, HandlerInterceptor это штатный механизм веб-слоя. У него три метода: preHandle до вызова контроллера (можно остановить обработку), postHandle после контроллера, но до отрисовки представления, и afterCompletion после завершения, включая случай с исключением.

Типичные задачи: проверка прав и заголовков, журналирование с временем выполнения, подстановка сквозного идентификатора запроса, метрики, ограничение частоты обращений.

Ключевое отличие от фильтра сервлета стоит проговорить самому:

• фильтр работает уровнем ниже, до DispatcherServlet, видит сырые запрос и ответ и ничего не знает про контроллеры. Годится для сжатия, CORS, безопасности, оборачивания тела запроса;
• перехватчик работает внутри веб-слоя Spring и знает, какой обработчик будет вызван, то есть может смотреть на аннотации метода контроллера. Отсюда и удобство для проверок, зависящих от конкретной ручки.

Рядом стоит назвать соседние инструменты, чтобы было видно понимание всей цепочки: @ControllerAdvice для единой обработки исключений и подготовки моделей, аспекты (AOP) для сквозной логики уровня сервисов, а в реактивном стеке вместо перехватчиков используются WebFilter.

Регистрируются перехватчики через WebMvcConfigurer с указанием путей, на которые они распространяются.

Где спотыкаются

Пытаются менять тело ответа в postHandle: там оно может быть уже записано, для этого нужен фильтр с обёрткой.

Кладут в перехватчик бизнес-логику, которой место в сервисе.

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