스프링에서 filter와 interceptor는 무슨 차이가 있을까? 기능적인 측면으로 본다면 유사한점이 있어 디테일한 차이점에 대해서는 생각해보질 않았다. 내가 공부했던 것을 정리해 보겠다.(참조 : https://goddaehee.tistory.com/154)
Spring Request Life Cycle
위 이미지는 Spring Request의 처리 순서를 보여준다. 여기서 주요할 점은 Filter, Interceptor 추가로 AOP 순서대로 request가 처리된다. 음 처리 순서는 이제 알겠다. Filter -> Interceptor -> AOP 순으로 처리된다. 여기서 Filter, Interceptor, AOP의 목표는 반복적인 처리코드 (권한체크, 로그인처리..)를 Controller 밖으로 꺼내서 개발에 효율성을 높여주기 위해서이다. 하지만 차이점은 모르겠다. 먼가 이유가 있기 때문에 위 3개를 만들지 않았을까 싶다.
Filter 와 Interceptor의 차이점
여러 글을 읽어보던 중 가장 공감이 되는 글을 찾았다.(https://supawer0728.github.io/2018/04/04/spring-filter-interceptor/)
Filter와 Interceptor의 차이점을 구글링하면 모두가
- 실행시점이 다르다
- Filter-WebAppplication등록, Interceptor-SpringContext에 등록
이 두개를 언급한다. 하지만 내가 알고싶은 왜 3개를 따로 만들었을까에 대한 답이 되지 않았다.
소스코드의 차이
구현할 메소드에서 차이가 생기지 않을까 생각돼서 내부 소스코드를 찾아봤다.
위 코드에서 차이점은 파라미터와 예외처리에서 나타단다.
Handler
Interceptor에는 handler를 추가로 가져온다 여기서 내가 찾은 유의미한 차이는 Filter는 유저의 request자체만을 보고 Interceptor는 Spring이 맵핑한 핸들러 정보를 알 수 있다는 것이다. 그렇기 때문에 각 컨트롤러에 대한 세부적인 권한체크가 Interceptor에서 가능하다.
ServletRequest
Filter는 ServletRequest로 받고 Interceptor는 HttpServletRequest으로 받는 차이가 있는데
ServletRequest에서는 Http Body 내용을 여러번 읽을 수 있다고 한다.
내가 중요하다 생각했던 예외처리의 차이점
Filter의 경우 request에 대한 에러가 발생할 경우 Web Application에 정의한 Error 페이지가 랜딩된다. 하지만 Interceptor의 경우 Dispatcher Servlet내에서 에러를 처리 할 수 있으므로 디테일한 에러 처리가 가능하다.
다른 중요한 차이점
Filter와 Interceptor의 차이점이 허물어저 가고 있지만 자신이 개발해야할 상황을 인지해야만 Filter 또는 Interceptor을 사용해야 할지 분명해진다. Filter는 Spring이전의 정적인 HTTP 처리에 사용하고 Interceptor는 서비스로직을 활용할 수 있는 애플리케이션 단위의 조작이 필요할때 사용한다.
