Difference between Interceptor and Filter in Spring MVC

java

spring-mvc

interceptors

filters

byAnton Shumikhin·Feb 4, 2025

In the Spring MVC world, Interceptors are the puzzle's integral parts, imparting defined behaviour around controller execution. They relish tight integration with Springs' influences and configurations. On the flip side, lying on the Java Servlet technology bed, Filters operate more generally, modifying any request irrespective of whether Spring handles it or not.

// Interceptor example:
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
    // “Knock Knock.” “Who's there?” – Your pre-controller code.
    return true; // Continue with the execution
}

@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, 
                       Object handler, ModelAndView modelAndView) {
    // “Knock Knock.” “Who?” – Your post-controller code.
}

// Filter example:
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
        throws IOException, ServletException {
    // Your filter code playing “Simon says” before chain.doFilter
    chain.doFilter(request, response); // Continue playing Simon says with the filter chain
    // Simon has spoken; your code after chain.doFilter
}

Interceptors, yep, they got your back for tasks specifically wrapped around Spring's internal mechanics or if the Spring context is essential. While Filters enhance the broader scope of request/response modifications that prefers to stay aloof from the Spring ecosystem.

Detailed exploration

Interceptors: Full Spring integration

Spring's native Interceptors possess the “special sauce” to carry out operations both before and after the request is handled by the controller. They offer the opportunity to stack multiple interceptors, thereby owning more granular control over request handling. If you need to conduct authorization checks or anything that requires the HandlerMethod's awareness, Interceptors got you covered.

Filters: Servlet API specialists

The Java Servlet-based Filters work seamlessly across frameworks. They are not bound to operate within Spring MVC, possessing the authority to vary the incoming and outgoing HTTP requests. The magic shines through when a task calls for data compression, encoding transformations, or authentication – challenging operations that demand a more comprehensive application perspective, perfectly fitting the Filters' gambit.

Battle of Use Cases

The Filters, owing to their raw request transformation skills, logging, or HTTP header set up prowess, fit like a glove for concerns operating outside Spring's tenure. As for Interceptors, they are the knights in shining armour for tweaks related to Spring's internals, like altering the overall procedural rhythm around the controller, operating within the Spring context, or dealing with Handler-sensitive tasks.

Best practices

Lord Filters prefers the web.xml royal court or rules the Java Config land with the @WebFilter decree for matters concerning Servlet, providing it with a sense of initiation and request/response transformations. The Interceptors, being part of the Spring circle, favour a declaration within Spring's context through the MVC configuration utilizing WebMvcConfigurerAdapter, or opt for a HandlerInterceptor direct application for more sophisticated behaviour.

Comprehending and identifying each one's role can lead to an elegant, efficient architecture without any overlapping responsibilities.

Java EE and Spring: A Harmonious Blend

Java EE foundation

Filters, the brainchild of Java EE, kick into action for incoming requests before they encounter any servlet. Be it managing sessions, controlling request/response formats, or other tasks happening before the core logic inside doFilter(), Filters have got it covered.

Spring's special

In contrast, Spring brainstormed and came up with its own HandlerInterceptor interface to allow post-DispatcherServlet interventions. It means the Interceptor has the chance to add further processing, that too after DispatcherServlet has confirmed the controller handling the request.

Testing and Debugging

Due to their architecture positioning, Filters can be slightly challenging to debug, with errors posing a difficulty in tracing if not managed efficiently. Therefore, verifying servlet container initialization and request/response transformations should be the focus while testing Filters.

As Interceptors are part of the Spring lifecycle, debugging is relatively more straightforward because issues often show up within the Spring MVC execution flow. As a rule of thumb, unit testing of individual interceptor methods like preHandle, postHandle, and afterCompletion is highly recommended.

explain-codes / Java / Difference between Interceptor and Filter in Spring MVC

Linked

Spring Boot Adding HTTP Request Interceptors



Spring MVC - How to get all request params in a map in Spring controller?



How do you create a REST client for Java?



How to get active user's UserDetails



How to manage exceptions thrown in filters in Spring?

