Différence entre l'intercepteur et le filtre dans Spring MVC

Je suis un peu confus sur les objectifs Filteret les Interceptorobjectifs.

Comme je l'ai compris à partir de la documentation, Interceptorest exécuté entre les demandes. D'autre part, il Filterest exécuté avant le rendu de la vue, mais après le rendu de la réponse par le contrôleur.

Alors, où est la différence entre postHandle()dans Interceptor et doFilter()dans Filter?

Quelle est la meilleure pratique dans quels cas d'utilisation doit-elle être utilisée? Dans cette image où fonctionne Filters et Interceptors?

Depuis HandlerIntercepterle javadoc de :

HandlerInterceptorest fondamentalement similaire à un servlet Filter, mais contrairement à ce dernier, il autorise simplement un prétraitement personnalisé avec la possibilité d'interdire l'exécution du gestionnaire lui-même et un post-traitement personnalisé. Les filtres sont plus puissants, par exemple, ils permettent d'échanger les objets de requête et de réponse transmis le long de la chaîne. Notez qu'un filtre est configuré dans web.xml, a HandlerInterceptordans le contexte de l'application.

En tant que directive de base, les tâches de prétraitement à granularité fine liées au gestionnaire sont des candidats pour les HandlerInterceptorimplémentations, en particulier le code de gestionnaire commun et les vérifications d'autorisation. D'autre part, a Filterest bien adapté pour la gestion du contenu des requêtes et des vues, comme les formulaires en plusieurs parties et la compression GZIP. Cela montre généralement quand on a besoin de mapper le filtre à certains types de contenu (par exemple des images), ou à toutes les demandes.

Cela étant dit:

Alors, où est la différence entre Interceptor#postHandle()et Filter#doFilter()?

postHandlesera appelé après l'appel de la méthode du gestionnaire mais avant le rendu de la vue. Ainsi, vous pouvez ajouter plus d'objets de modèle à la vue, mais vous ne pouvez pas modifier le HttpServletResponsecar il est déjà validé.

doFilterest beaucoup plus polyvalent que le postHandle. Vous pouvez modifier la demande ou la réponse et la transmettre à la chaîne ou même bloquer le traitement de la demande.

De plus, dans les méthodes preHandleet postHandle, vous avez accès à HandlerMethodqui a traité la demande. Ainsi, vous pouvez ajouter une logique de pré / post-traitement basée sur le gestionnaire lui-même. Par exemple, vous pouvez ajouter une logique pour les méthodes de gestionnaire qui ont des annotations.

Quelle est la meilleure pratique dans quels cas d'utilisation doit-elle être utilisée?

Comme l'a dit le document, les tâches de prétraitement à granularité fine liées au gestionnaire sont des candidats pour les HandlerInterceptorimplémentations, en particulier le code de gestionnaire commun et les vérifications d'autorisation. D'autre part, a Filterest bien adapté pour la gestion du contenu des requêtes et des vues, comme les formulaires en plusieurs parties et la compression GZIP. Cela montre généralement quand on a besoin de mapper le filtre à certains types de contenu (par exemple des images), ou à toutes les demandes.

Filtre : - Un filtre comme son nom l'indique est une classe Java exécutée par le conteneur de servlet pour chaque requête HTTP entrante et pour chaque réponse http. De cette façon, il est possible de gérer les requêtes HTTP entrantes avant qu'elles n'atteignent la ressource, comme une page JSP, un servlet ou une simple page statique; de la même manière, il est possible de gérer la réponse HTTP sortante après l'exécution de la ressource.

Intercepteur : - Les intercepteurs Spring sont similaires aux filtres de servlet mais ils agissent dans le contexte Spring, ils sont donc nombreux à gérer les requêtes et réponses HTTP, mais ils peuvent implémenter un comportement plus sophistiqué car ils peuvent accéder à tout le contexte Spring.

Un HandlerInterceptor vous donne un contrôle plus fin qu'un filtre, car vous avez accès au "gestionnaire" cible réel - cela signifie que toute action que vous effectuez peut varier en fonction de ce que la requête fait réellement (alors que le filtre de servlet est appliqué de manière générique à toutes les demandes - seulement capable de prendre en compte les paramètres de chaque demande). Le handlerInterceptor fournit également 3 méthodes différentes, afin que vous puissiez appliquer un comportement avant d'appeler un gestionnaire, une fois le gestionnaire terminé mais avant le rendu de la vue (où vous pouvez même ignorer complètement le rendu de la vue), ou après que la vue elle-même a été rendue. De plus, vous pouvez configurer différents intercepteurs pour différents groupes de gestionnaires - les intercepteurs sont configurés sur le handlerMapping et il peut y avoir plusieurs handlerMappings.

Par conséquent, si vous avez besoin de faire quelque chose de complètement générique (par exemple, consigner toutes les demandes), alors un filtre est suffisant - mais si le comportement dépend du gestionnaire cible ou si vous voulez faire quelque chose entre la gestion de la demande et le rendu de la vue, alors le HandlerInterceptor offre cette flexibilité.

Référence: http://static.springframework.org/sp...ng-interceptor