필터와 인터셉터
1. 필터
- 스프링 외부의 서블릿에서 제공하는 공통처리 기능
- 스프링 내로 요청이 들어오기 전과 스프링의 요청이 나갈 때 처리 가능
- 조금 더 low level 처리 가능
1-2. 필터 흐름 : HTTP 요청 > WAS > 필터 > 서블릿(스프링의 디스패쳐 서블릿) > 컨트롤러
- 적절하지 않은 요청인 경우 필터는 서블릿 호츨 X
1-3.
필터 인터페이스를 구현하고 등록하면 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고 관리
- init() : 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출
- doFilter() : 고객의 요청이 올 때마다 해당 메서드 호출, 필터의 로직을 구현하면 된다
- destroy() : 필터 종료 메서드. 서블릿 컨테이너가 종료될 때 호출
2. 인터셉터
- 스프링MVC 에서 제공하는 공통처리 기능
- 실제 매핑된 handler 정보 확인 가능 (어떤 것이 실제 내 요청 처리하는지 확인 가능)
- 조금 더 상세한 조건식과 세부적인 스펙(post, pre, after) 를 통해 구체적인 시점에 구체적인 동작 가능
- AOP 와 비교한다면 AOP 는 인터셉터보다 더 구체적인 조건 (어노테이션, 파라미터, 주소 등) 과 동작 위치 (afterThrowing 등) 을 갖음
2-1. 인터셉터 흐름 : HTTP 요청 > WAS > 필터 > 서블릿 > 스프링 인터셉터 > 컨트롤러
- 스프링 인터셉터는 디스패쳐 서블릿과 컨트롤러 사이에서 컨트롤러 호출 직전에 호출
- 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패쳐 서블릿 이후에 등장
(스프링 MVC 의 시작점 = 디스패쳐 서블릿)
- 인터셉터의 URL 패턴은 서블릿의 URL 패턴과 달리 매우 정밀함
- 적절하지 않은 요청인 경우 인터셉터는 컨트롤러 호출 X
예시. 인터셉터 체인
ex. 로그를 남기는 인터셉터 1 > 로그인 여부를 체크하는 인터셉터 2
2-2. HandlerInterceptor 를 구현 (implements)
- 호출 전 / preHandle() :
- 호출 후 / postHandle() : 컨트롤러 예외 발생시 호출 X
- 요청 완료 이후 / afterHandle() : 항상 호출, 예외랑 무관하게 공통처리시 사용
* 서블릿 필터의 경우 단순하게 doFilter() 하나만 제공
* 서블릿 필터의 경우 단순히 request, response 만 제공했지만,
인터셉터는 어떤 컨트롤러(handler)가 호출되는지 , 어떤 (modelAndView) 가 변환되는지 응답 정보도 받을 수 있다.