Difference between Interceptor and Filter in Spring MVC

后端 未结 3 799
盖世英雄少女心
盖世英雄少女心 2020-12-04 04:57

I\'m a little bit confused about Filter and Interceptor purposes.

As I understood from docs, Interceptor is run between reque

3条回答
  •  醉酒成梦
    2020-12-04 05:36

    From HandlerIntercepter's javadoc:

    HandlerInterceptor is basically similar to a Servlet Filter, but in contrast to the latter it just allows custom pre-processing with the option of prohibiting the execution of the handler itself, and custom post-processing. Filters are more powerful, for example they allow for exchanging the request and response objects that are handed down the chain. Note that a filter gets configured in web.xml, a HandlerInterceptor in the application context.

    As a basic guideline, fine-grained handler-related pre-processing tasks are candidates for HandlerInterceptor implementations, especially factored-out common handler code and authorization checks. On the other hand, a Filter is well-suited for request content and view content handling, like multipart forms and GZIP compression. This typically shows when one needs to map the filter to certain content types (e.g. images), or to all requests.

    With that being said:

    So where is the difference between Interceptor#postHandle() and Filter#doFilter()?

    postHandle will be called after handler method invocation but before the view being rendered. So, you can add more model objects to the view but you can not change the HttpServletResponse since it's already committed.

    doFilter is much more versatile than the postHandle. You can change the request or response and pass it to the chain or even block the request processing.

    Also, in preHandle and postHandle methods, you have access to the HandlerMethod that processed the request. So, you can add pre/post-processing logic based on the handler itself. For example, you can add a logic for handler methods that have some annotations.

    What is the best practise in which use cases it should be used?

    As the doc said, fine-grained handler-related pre-processing tasks are candidates for HandlerInterceptor implementations, especially factored-out common handler code and authorization checks. On the other hand, a Filter is well-suited for request content and view content handling, like multipart forms and GZIP compression. This typically shows when one needs to map the filter to certain content types (e.g. images), or to all requests.

提交回复
热议问题