개요
이전에 AOP, Interceptor, Filter에 대해 찾아본 적이 있다.
각각의 동작하는 시점 정도는 이해하고 넘어갈 수 있었지만, 정확히 어떤 상황에 어떤 방식을 사용하는지 명확하게 이해하지 못했었다.
이번에 프로젝트를 진행하면서 질문글에는 좋아요만 답변글에는 고마워요만 누를 수 있게 해야하는 부분이 있는데 각각의 비즈니스 로직 코드에 끼워넣는것 보다 위의 기능들을 사용하여 구현하고 싶었다.
위의 3가지 방식이 어떤 상황에 사용되는지 공부하며 어떤 방식이 가장 적합한 방식인지 알아보려한다.
Filter, Interceptor, AOP 흐름
Filter, Interceptor, AOP 모두 공통 요청을 처리하는데 관련이 되어있다.
여러 요청들에서 공통으로 처리해야 하는 내용들이 있는데, 이 때 위 3가지를 이용하여 공통으로 처리 할 수 있다.
Filter, Interceptor, AOP 는 위와 같은 흐름으로 실행된다.
- 요청이 들어오게 되면 request > Filter > Servlet > Interceptor > AOP > Controller순으로 실행
- 응답은 역순인 Controller > AOP > Interceptor > Filter > Response 순으로 실행
- DisptacherServlet, Interceptor, AOP, Controller 는
Spring Context에 속하고, Filter 의 경우에는Web Context에 속함
즉 Filter, Interceptor, AOP의 가장 큰 차이점은 요청을 처리하는 위치와 속한곳이다.
다음으로는 각각의 특징과 어떤 상황에 사용되는지 알아보자.
Filter
Filter에서는 주로 스프링과 무관한 전역적인 요청을 처리한다.
Filter는 Spring에 들어오기 전에 실행되며 톰캣과 같은 웹 컨테이너(WAS)에서 처리를 해주게 된다. 그렇기에 Request에 대한 조작이 가능하다. Interceptor와 AOP는 모두 Request의 내용을 가지고 추가적인 작업을 해야 하는 입장이지만, Filter는 그 요청 자체를 조작할 수 있다.
그렇기에 아래와 같은 작업에 적합하다.
- 공통된 보안 및 인증/인가 관련 작업
- 이미지/데이터 압축 및 문자열 인코딩
- Spring과 분리되어야 하는 기능
- 모든 요청과 응답에 대한 로깅
Interceptor
Filter와의 가장 큰 차이점은 스프링의 모든 빈 객체에 접근할 수 있다는 점이다. 추가로 Interceptor에서는 filter와는 다르게 트랜잭션과 관련된 처리도 진행할 수 있다.
Interceptor는 여러 개를 등록할 수 있으며, 한 개 이상의 Interceptor가 등록되어 있는 경우 요청은 Interceptor를 거쳐 컨트롤러에 전달되며, Interceptor가 존재하지 않는 경우에는 즉시 컨트롤러로 요청이 전달된다.
주로 아래와 같은 작업에 적합하다.
- 세부적인 보안 및 인증/인가 작업
- API 호출에 대한 로깅 또는 검증
- Controller로 넘겨주는 정보의 가공
AOP
Interceptor나 Filter와는 달리 메소드 전후의 지점에 자유롭게 설정이 가능하다.Interceptor와 Filter는 주소로 대상을 구분해서 걸러내야하는 반면, AOP는 주소, 파라미터, 애노테이션 등 다양한 방법으로 대상을 지정할 수 있다.
AOP의 Advice와 HandlerInterceptor의 가장 큰 차이는 파라미터의 차이다.Advice의 경우 JoinPoint나 ProceedingJoinPoint 등을 활용해서 호출한다. 반면 HandlerInterceptor는 Filter와 유사하게 HttpServletRequest, HttpServletResponse를 파라미터로 사용한다.
주로 아래와 같은 작업에 적합하다.
- 로깅
- 트랜잭션
- 에러 처리
- 세부적인 비즈니스 로직, 메소드와 관련된 처리
요약
위와 같이 간단한 특징과 상황에 맞는 방식을 알아봤는데, 내용을 정리하면서 내가 알아보려한 제약 로직(유효성 검증)은 API 호출에 대한 검증이라 판단하여 Interceptor에서 사용하는게 그나마 적합하지 않을까 하는 결론을 내렸다.
