Diferença entre interceptor e filtro no Spring MVC

Estou um pouco confuso sobre Filtere Interceptorpropósitos.

Como eu entendi nos documentos, Interceptoré executado entre as solicitações. Por outro lado, Filteré executado antes da exibição de renderização, mas depois da resposta renderizada do Controlador.

Então, onde está a diferença entre postHandle()no Interceptor e doFilter()no Filtro?

Qual é a prática recomendada em que casos de uso deve ser usado? Nesta foto onde funciona Filters e Interceptors?

A partir HandlerIntercepterde javadoc :

HandlerInterceptoré basicamente semelhante a um Servlet Filter, mas em contraste com o último, ele apenas permite o pré-processamento personalizado com a opção de proibir a execução do próprio manipulador e o pós-processamento personalizado. Os filtros são mais poderosos, por exemplo, eles permitem a troca de objetos de solicitação e resposta que são transmitidos ao longo da cadeia. Observe que um filtro é configurado em web.xml, a HandlerInterceptorno contexto do aplicativo.

Como uma diretriz básica, tarefas de pré-processamento relacionadas ao manipulador de baixa granularidade são candidatas a HandlerInterceptorimplementações, especialmente código de manipulador comum fatorado e verificações de autorização. Por outro lado, a Filteré adequado para solicitar conteúdo e visualizar manipulação de conteúdo, como formulários multipartes e compactação GZIP. Isso normalmente mostra quando é necessário mapear o filtro para certos tipos de conteúdo (por exemplo, imagens) ou para todas as solicitações.

Com isso dito:

Então, onde está a diferença entre Interceptor#postHandle()e Filter#doFilter()?

postHandleserá chamado após a invocação do método do manipulador, mas antes da exibição ser renderizada. Assim, você pode adicionar mais objetos de modelo para a vista, mas você pode não mudar o HttpServletResponseuma vez que já está comprometido.

doFilteré muito mais versátil que o postHandle. Você pode alterar a solicitação ou resposta e passá-la para a cadeia ou até mesmo bloquear o processamento da solicitação.

Além disso, nos métodos preHandlee postHandle, você tem acesso ao HandlerMethodque processou a solicitação. Portanto, você pode adicionar lógica de pré / pós-processamento com base no próprio manipulador. Por exemplo, você pode adicionar uma lógica para métodos manipuladores que possuem algumas anotações.

Qual é a prática recomendada em que casos de uso deve ser usado?

Como o documento disse, as tarefas de pré-processamento relacionadas ao manipulador de baixa granularidade são candidatas a HandlerInterceptorimplementações, especialmente o código do manipulador comum fatorado e as verificações de autorização. Por outro lado, a Filteré adequado para solicitar conteúdo e visualizar manipulação de conteúdo, como formulários multipartes e compactação GZIP. Isso normalmente mostra quando é necessário mapear o filtro para certos tipos de conteúdo (por exemplo, imagens) ou para todas as solicitações.

Filtro : - Um filtro como o nome sugere é uma classe Java executada pelo contêiner de servlet para cada solicitação HTTP de entrada e para cada resposta http. Dessa forma, é possível gerenciar as solicitações de entrada HTTP antes que elas cheguem ao recurso, como uma página JSP, um servlet ou uma página estática simples; da mesma forma, é possível gerenciar a resposta de saída HTTP após a execução do recurso.

Interceptor : - Spring Interceptors são semelhantes aos Servlet Filters, mas eles atuam no Spring Context, portanto, são muitos poderosos para gerenciar solicitações e respostas HTTP, mas podem implementar um comportamento mais sofisticado porque podem acessar todo o contexto Spring.

Um HandlerInterceptor oferece um controle mais refinado do que um filtro, porque você tem acesso ao "manipulador" de destino real - isso significa que qualquer ação que você executa pode variar dependendo do que a solicitação está realmente fazendo (enquanto o filtro de servlet é aplicado genericamente a todos os pedidos - apenas capaz de levar em consideração os parâmetros de cada pedido). O handlerInterceptor também fornece 3 métodos diferentes, para que você possa aplicar o comportamento antes de chamar um manipulador, depois que o manipulador for concluído, mas antes da renderização da visualização (onde você pode até ignorar a renderização da visualização por completo) ou depois que a própria visualização foi renderizada. Além disso, você pode configurar diferentes interceptores para diferentes grupos de manipuladores - os interceptores são configurados no handlerMapping e pode haver vários handlerMappings.

Portanto, se você precisa fazer algo completamente genérico (por exemplo, registrar todas as solicitações), um filtro é suficiente - mas se o comportamento depende do manipulador de destino ou você deseja fazer algo entre o tratamento da solicitação e a renderização da visualização, então o HandlerInterceptor fornece essa flexibilidade.

Referência: http://static.springframework.org/sp...ng-interceptor