🚀 간단한 사용 예시

클라이언트가 URL요청을 보낼 경우 해당 URL 매핑을 가지는 Controller에서 해당 메서드를 실행 시킬 것이다.

( 🤦🏻‍♀️ 위와 같은 과정은 간단해 보이지만 DispatcherServlet을 통해 여러 과정들이 일어난다.)

이때, 요청 흐름들 사이에 로직을 끼워넣을 수 있게 도와주는 인터페이스이다.

제일 대표적인 예시로 로그인이 있다. 예를들어 로그인하지 않은 상태로 글쓰기 폼이나 회원정보 수정 폼을 URL에 입력해서 들어가지는건 매우 이상하다.

이러한 상황이 있을때 로그인 화면으로 이동시키는 것이 좋은 방법이다.

그런데 웹 어플리케이션에서 각 기능들을 구현한 컨트롤러 코드마다 로그인 확인 여부 코드를 삽입하는것은 많은 중복을 일으킨다.

이때 다수의 컨트롤러에 동일한 기능을 적용해야 할 때 사용할 수 있는것이 HandlerInterceptor이다.

🚀 HandlerInterceptor 구현및 흐름

HandlerInterceptor 인터페이스엔 자주 쓰이는 3가지 메서드가 있다.

HandlerInterceptor 인터페이스의 메서드들은 전부 default(JAVA8 이후)로 되어 있으므로 원하는 메서드만 구현하면 된다.

• preHandle() : 컨트롤러(핸들러) 실행 전
• postHandle() : 컨트롤러의 요청 메서드가 실행된 후에 실행.(뷰를 실행하기 전)
• afterCompletion() : 뷰를 실행한 이후

🚀 Filter & Interceptor

Interceptor를 사용하던 중 spring없이 servlet/jsp로 웹을 구현할때 filter라는것을 사용한것이 떠올랐다.

기능들이 비슷해 보였지만 다른점들이 분명 있었다.

1. Filter와 Interceptor는 실행되는 시점이 다르다.

Filter : Web Application에 등록

Interceptor : Spring Context에 등록

2. 예외 처리의 방식이 다르다.

Filter 의 경우 예외가 발생하면 Web Applications에서 처리한다. was를 톰캣으로 사용할 경우 Filter 내에서 예외를 잡아서 예외처리를 미뤄야 한다.

Interceptor 의 경우 DispatcherServlet라는 강력한 기능 내에 있으므로 ControllerAdvice에서 ExceptionHandler를 사용해 예외처리를 할 수 있다.

이처럼 Interceptor의 예외처리는 Filter에 비해 견고하다고 할 수 있다.

🚀 마지막으로..

JSP/Servlet을 할 당시엔 수많은 웹 어플리케이션의 각 기능마다 동일한 기능을 적용해야 한다는 생각에 암울했었지만 Interceptor 를 알게 된 후에 너무 기뻤다... (그땐 Filter로 처리해 줄 생각도 못 했었다 ㅠㅠ)