스프링 필터 기능과 마찬가지로 인터셉터 기능도 공통 관심 사항을 처리하지만, 적용되는 순서와 범위 그리고 사용방법이 다르다

간단하게 흐름을 보자면 아래와 같다.

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러

그렇다 인터셉터(가로막는)의 어원처럼 dispatcherServlet과 컨트롤러 호출 사이에서 호출된다

로그인 비로그인의 흐름을 나타내보자면 아래와 같겠다

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 //로그인 사용자
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출
X) // 비 로그인 사용자

스프링 인터셉터도 필터처럼 체인형식인데, 필터보다 더 편리하고 정교한 기능을 제공한다.

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 인터셉터1 -> 인터셉터2 -> 컨트롤러

스프링의 인터셉터를 사용하려면 HandlerInterceptor 인터페이스를 구현하면 된다.

@Slf4j
public class LogInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    }
}

서블릿 필터의 경우 doFilter() 하나만 제공되지만, 인터셉터는 단계적으로 잘 세분화 되어있다. 그리고 매개변수도 어떤 컨트롤러(handler)가 호출되는지의 호출정보, 어떤 modelView가 반환되는지, Exception까지 받아볼 수 있다. 이 얼마나 정교한가!

단계적으로 잘 세분화되어있단 말은 아래 그림을 보면 더 이해가 잘 갈 것이다.

image.png