[Spring] Filter와 Interceptor 차이

 

Spring에서는 비즈니스 로직과 분리되어 공통적으로 처리해야 하는 업무를 수행하기 위한 몇가지의 기능들을 지원한다.

 

1. Filter (필터)
2. Interceptor(인터셉터)
3. AOP(관점 지향 프로그래밍)

 

위와 같은 기능은 공통적으로 사용되는 기능을 모듈화하여 비즈니스 로직과 분리하여 재사용성과 유지보수성을 높이고 중복 코드를 제거한다.

AOP는 애플리케이션 전체에 걸쳐 공통으로 사용되는 기능을 지원한다면, Filter와 Interceptor는 주로 Controller 레이어에서 사용되며 클라이언트의 요청과 응답을 가로채 처리하게 된다.

 

 

Filter와 Interceptor의 차이점을 중점적으로 정리해보자.

---

Filter

J2EE 표준 스펙 기능으로 디스패처 서블릿(Dispatcher Servlet)에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가적인 작업을 처리할 수 있는 기능을 제공한다.

(J2EE는 자바 기술로 기업환경의 어플리케이션을 만드는데 필요한 스펙들을 모아둔 스펙 집합이라고 합니다)

 

스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너(서블릿 컨테이너)에 의해 관리 된다. 때문에 필터는 스프링에서 처리해주는 내용을 적용받을 수 없으며 스프링에 의한 예외처리가 되지않는다. 따라서 예외를 핸들링하기 위해선 별도의 예외처리가 필요하다.

 

 

필터를 추가하기 위해 javax.servlet의 Filter 인터페이스를 구현해야 한다.

public interface Filter {

    public default void init(FilterConfig filterConfig) throws ServletException {}

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
    					throws IOException, ServletException;

    public default void destroy() {}
}

doFilter 메소드

url 패턴에 맞는 모든 HTTP 요청을 디스패처 서블릿으로 전달되기전에 웹 컨테이너에 의해 실행되는 함수이다. doFilter의 파라미터로 FilterChain이 있는데, FilterChain의 doFilter를 통해 다음 대상으로 요청을 전달하게 된다. 우리가 필요한 처리 과정을 넣어줌으로써 원하는 처리를 진행 할 수있다.

 

 

이때 필터가 다음 필터를 호출하기 위해 필터 체이닝을 해줄때, Requst와 Response 객체를 넘겨주므로 울리는 해당 요청과 응답을 우리가 원하는 다른 객체로 바뀌치기가 가능하다.

public TestFilter implements Filter {

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        // 개발자가 다른 request와 response를 넣어줄 수 있음
        chain.doFilter(new MockHttpServletRequest(), new MockHttpServletResponse());       
    }
}

즉, 요청와 응답 객체를 조작할 수 있다.

 

 

Spring Security를 통해 Filter를 익숙하게 접할 수 있는데, Spring Security가 Spring MVC에 종속적이지 않는다는 특징을 갖는 이유가 필터를 기반으로 인증/인가를 처리하기 때문이다.

 

 

Interceptor

필터와 달리 Spring에서 제공하는 기술로, 디스패처 서블릿이 컨트롤러를 호출하기 전/후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공한다. 즉, 인터셉터는 스프링 컨텍스트에서 동작한다.

 

디스패처 서블릿은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청하는데, 그 결과로 HandlerExecutionChain(실행 체인)을 돌려준다. 이 실행 체인은 1개 이상의 인터셉터가 등록되어 있다면 순차적으로 인터셉터들을 거쳐 컨트롤러가 실행되도록 하고, 인터셉터가 없으면 바로 컨트롤러를 실행한다.

(인터셉터가 컴트롤러에게 요청을 위임하는 것은 아니며 위 그림은 처리 순서를 도식화한 것이다.)

 

 

 

인터셉터를 추가하기 위해서는 org.springframework.web.servlet의 HandlerInterceptor 인터페이스를 구현해야한다.

public interface HandlerInterceptor {

    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
        return true;
    }

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

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

preHandler 메소드

컨트롤러가 호출되기 전에 실행되어 컨트롤러 이전이 처리해야하는 전처리 작업이나 요청 정보를 가공하거나 추가하는 경우에 사용한다.

handler 파라미터는 핸들러 매핑이 찾아준 컨트롤러 빈에 매핑되는 HandlerMethod라는 타입의 객체로, @RequestMapping이 붙은 메소드의 정보를 추상화한 객체이다. (무슨말인지 잘 모르겠다)

boolean 타입을 반환하며 반환값이 true이면 다음 단계로 진행되지만, false라면 작업이 중단되며 이후 작업은 진행되지 않는다.

 

 

이때 디스패처 서블릿은 여러 인터셉터 목록을 가지고 있으며, for문을 통해 순차적으로 실행시킨다. boolean 타입을 반환하여 다음 인터셉터의 실행 유무를 알려줄뿐 Request와 Response 객체는 넘겨줄 수 없기때문에 필터와 달리 요청, 응답을 가공할순없다. (객체 자체를 조작할 수는 없으나 내부적으로 갖는 값은 조작이 가능하다. 가공 가능)

public class TestInterceptor implements HandlerInterceptor {

    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        // Request/Response를 교체할 수 없고 boolean 값만 반환할 수 있다.
        return true;
    }
}

 

 

postHandler 메소드

컨트롤러를 호출한 후에 실행된다. 컨트롤러가 반환하는 ModelAndView 타입이 정보가 제공된느데, 최근에는 Json 형태로 데이터를 제공하는 RestAPI 기반 컨트롤러를 만들면서 자주 사용되지 않는다.

 

 

afterCompletion 메소드

모둔 뷰에서 최종 결과를 생성하는 일을 모함해 모든 작업이 완료된 후에 실행하게 된다. postHandler와 달리 컨트롤러 하위 계층에서 예외가 발생하더라도 해당 메소드는 반드시 호출된다.

 

 

❗️ 컨트롤러에 적용할 부가기능을 AOP가 아닌 인터셉터를 사용하는 이유

     → 컨트롤러는 타입이 일정하지 않고 호출 패턴도 제각각이라 컨트롤러에 AOP를 적용하려면 번거로운 부가작업들이 생긴다.

     → AOP에서는 HttpServletRequest/Response 객체를 얻기 어렵다.

 

 

---

사용목적

Filter

필터는 Spring과 무관하게 전역적으로 처리해야하는 작업들을 처리할 수 있다. 웹 어플리케이션에 전반적으로 사용되는 기능을 구현할때 적합.

인터셉터보다 앞단에서 동작하기 때문에 보안 검사를 하여 올바른 요청이 아닐 경우 차단할 수 있다. 스프링 컨테이너까지 요청이 전달되지 못하고 차단되므로 안정성을 더욱 높일 수 있다.

• 보안 및 인증/인가 작업
• 모든 요청에 대한 로깅, 검사
• 이미지, 데이터 압축
• 헤더 추가 및 인코딩 변경
• Spring과 분리되어야하는 기능

Interceptor

클라이언트의 요청과 관련되어 전역적으로 처리해야되는 작업들. Controller로 넘어가기전에 세부적인 검사와 처리를 하는데 적합하다. 애플리케이션의 비즈니스 로직과 관련된 작업을 수행할 수 있다.

필터와 달리 객체 자체를 조작할 수 없지만 대신 객체가 내부적으로 갖는 값은 조작할 수 있으므로 컨트롤러로 넘겨주기 위한 정보를 가공하기 용이하다.

• 세부적인 보안 및 인증/인가 공통 작업
• API 호출에 대한 로깅, 통계
• Controller로 넘겨주는 정보를 가공

 

 

 

정리

	Filter	Interceptor
동작 위치	웹 컨텍스트	스프링 컨텍스트
스프링의 예외처리	X	O
응답, 요청 객제 조작	O	X

 

✅ 한줄 정리?!

Filter와 Interceptor는 모두 비즈니스 로직과 분리되어 공통적으로 사용되는 기능을 모듈화여 처리하는 방식입니다. Filter는 웹 컨테이너에 위치하며 디스패처 서블릿에서 요청을 처리하기 전후에 동작하며 Interceptor는 스프링컨텍스트에서 동작하며 디스패처 서블릿을이 컨트롤러를 호출하기 전후에 동작합니다. 때문에 Filter의 경우 Spring과 무관한 작업(인증/인가, 데이터 압축, 인코딩)을 처리하고 Interceptor의 경우 애플리케이션 비즈니스 로직과 관련된 세부적인 검사를 처리하는데 주로 사용됩니다.

 

 

 

 

 

reference.

https://mangkyu.tistory.com/173

 

 

 

 

잘못된 정보가 있다면 댓글을 통해 알려주세요. 감사합니다.