[spring] Filter/Interceptor/Argument Resolver 제대로 알아보자

winkite·2024년 8월 27일
0

정리

목록 보기
5/7

맨날 순서 헷갈려서 이번에 제대로 정리해보려고 한다


일단 Filter, Interceptor, AOP의 흐름을 알아보자

(열심히 그려봤다)
Filter는 Web Context에 속하고 Interceptor와 AOP는 Spring Context에 속한다.
호출 순서는
요청이 들어오면 requset > Filter > Servlet > Interceptor > Argument Resolver > AOP > Controller 순으로 실행된다.

  • Filter
    Dispatcher Servlet에 전달되기 전에 처리를 할 수 있다.
    보통 요청에 대한 인증, 권한 체크 하는데 사용한다.
    (Header의 인증 토큰, url 패턴 검사 등등..)
  • Interceptor
    HTTP 요청을 가로채서 원하는 동작을 추가할 수 있다.
    컨트롤러에 집중된 기능을 처리하고, 공통 기능을 중앙에서 관리하고 재사용할 수 있다. (컨트롤러와 강한 결합)
    preHandler, postHandler, AfterCompletion 등의 메서드를 제공한다.
  • AOP
    관점 지향 프로그래밍의 개념을 기반으로 동작하며, 메서드 호출을 가로채서 전후에 부가적인 로직을 실행한다.
    이는 Interceptor와 Argument Resolver보다 먼저 실행될 수도 있다.
    주로 로깅, 트랙잭션 관리, 보안 등과 같은 공통에 사용한다.

그런데 이렇게 정리하다가 그럼 'Argumnet Resolver'는 언제 작동되는거지?...의문이 들었다.

찾아보니, Argument Resolver는 컨트롤러의 메서드가 호출되기 전에!
파라미터를 해석하고 변환한다고 한다.


이렇게 글로만 정리하니까 정확하게 이해하기에는 부족한 것 같다!
그래서 직접 구현해보면서 정리하는게 좋을 것 같다.

1. Filter vs Interceptor

  • Filter
public class TestFilter implements Filter {
	
	@Override
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // request, response 조작 가능
        chain.doFilter(request, response);
	}
}

Filter 인터페이스는 init, doFilter, destroy 3가지 메소드를 갖고 있다.
init과 filter는 필터가 생성, 소멸될 때 수행되는 메소드이고
doFilter는 Request, Response가 필터를 거칠 때 수행되는 메소드이다.

다음 필터가 있을 경우 전달하고 없을 때는 Servlet에게 요청을 전달하며,
request, response를 조작이 가능하다.

  • Interceptor
public class TestInterceptor implements HandlerInterceptor {
    
	@Override
	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // Controller로 요청을 전달하거나 중단할 수 있다.
        // request, response 조작 불가능
		return true;
	}
}

Interceptor 인터페이스는 preHandle, postHandle, afterCompetion 3가지 메소드를 갖고 있다.
preHandle은 Controller가 호출 되기 전,
postHandle은 Controller가 호출된 후에
afterCompletion은 모든 작업이 완료된 후에 실행되는 메서드 이다.

preHandle의 return 값이 boolean이기 때문에
true이면 Controller로 요청을 전달 false라면 요청을 중단한다.

filter와 interceptor 둘 다 request, response에 개입하여 주로 인가, 인증, 로깅 등의 용도로 사용하여 비슷하지만,
filter는 요청의 흐름자체를 변경할 수 있으며, 자체적으로 응답 생성할 수 있고
interceptor는 요청을 가로채서 특정 로직을 수행할 수 있다는 점에서 흐름을 제어하는데 초점이 맞춰져 있어 동작 방식과 시점에 차이가 있다.

2. Argument Resolver

  • Argument Resolver
public class TestArgumentResolver implements HandlerMethodArgumentResolver{

	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		// TODO Auto-generated method stub
		return true;
	}

	@Override
	public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
			NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
		
		return null;
	}

}

Argument resolver 인터페이스는 supportsParameter, resolveArgumnet를 가지고 있다.
supportParameter는 컨트롤러에서 파라미터를 주입할 때 조건을 만족하는지 확인한다. 조건을 만족하면(true) resolveArgument 메소드를 실행한다.

또한 custom으로 사용하기 위해서는 WebMvcConfigurer를 구현한 WebConfig 클래스에 등록해줘야 한다.


일단은 내가 이해하기 쉽게 작성했다
이제는 헷갈리지 말자!

profile
열심히 뛰는 개발자🏃

0개의 댓글