Estoy un poco confundido acerca Filtery Interceptorpropósitos.
Como entendí por los documentos, Interceptorse ejecuta entre solicitudes. Por otro lado, Filterse ejecuta antes de renderizar la vista, pero después de que Controller renderizara la respuesta.
Entonces, ¿dónde está la diferencia entre postHandle()Interceptor y doFilter()Filter?
¿Cuál es la mejor práctica en qué casos de uso debería utilizarse? En esta imagen, ¿dónde funciona Filtersy Interceptors?
Respuestas:
Desde HandlerIntercepter's javadoc :
HandlerInterceptores básicamente similar a un ServletFilter, pero a diferencia de este último, solo permite el preprocesamiento personalizado con la opción de prohibir la ejecución del propio controlador y el posprocesamiento personalizado. Los filtros son más potentes, por ejemplo, permiten intercambiar los objetos de solicitud y respuesta que se transmiten en la cadena. Tenga en cuenta que un filtro se configura enweb.xml, aHandlerInterceptoren el contexto de la aplicación.Como pauta básica, las tareas de preprocesamiento detalladas relacionadas con el controlador son candidatas para
HandlerInterceptorimplementaciones, especialmente el código de controlador común factorizado y las comprobaciones de autorización. Por otro lado, aFilteres adecuado para solicitudes de contenido y visualización de contenido, como formularios de varias partes y compresión GZIP. Por lo general, esto muestra cuando se necesita asignar el filtro a ciertos tipos de contenido (por ejemplo, imágenes) oa todas las solicitudes.
Con eso dicho:
Entonces, ¿dónde está la diferencia entre
Interceptor#postHandle()yFilter#doFilter()?
postHandlese llamará después de la invocación del método del controlador, pero antes de que se represente la vista. Por lo tanto, se puede añadir más objetos del modelo a la vista, pero puede no cambiar el HttpServletResponsepuesto que ya está comprometido.
doFilteres mucho más versátil que el postHandle. Puede cambiar la solicitud o respuesta y pasarla a la cadena o incluso bloquear el procesamiento de la solicitud.
Además, en los métodos preHandley postHandle, tiene acceso al HandlerMethodque procesó la solicitud. Por lo tanto, puede agregar lógica de procesamiento previo / posterior según el controlador en sí. Por ejemplo, puede agregar una lógica para los métodos de controlador que tienen algunas anotaciones.
¿Cuál es la mejor práctica en qué casos de uso debería utilizarse?
Como dijo el documento, las tareas de preprocesamiento detalladas relacionadas con el controlador son candidatas para HandlerInterceptorimplementaciones, especialmente el código de controlador común factorizado y las comprobaciones de autorización. Por otro lado, a Filteres adecuado para solicitudes de contenido y visualización de contenido, como formularios de varias partes y compresión GZIP. Por lo general, esto muestra cuando se necesita asignar el filtro a ciertos tipos de contenido (por ejemplo, imágenes) oa todas las solicitudes.
HandlerIntercepteres un concepto específico de Spring. Para registrar un filtro de servlet, puede registrarlo utilizando el antiguo web.xml(Servlet 2.5 y versiones anteriores) o el nuevo enfoque programático (Servlet 3+). Dado que HandlerIntercepteres solo una abstracción de Spring, debe registrarse en el contexto de Spring
WebApplicationcual es único por despachador, por lo que tanto el servlet como el filtro están asociados con el contexto, es una buena práctica asociar el interceptor y el filtro con el cual rootContextsi hay varios despachadores todos pueden compartir lo mismo.
Filtro : un filtro, como su nombre indica, es una clase Java ejecutada por el contenedor de servlets para cada solicitud HTTP entrante y para cada respuesta http. De esta forma, es posible gestionar las solicitudes entrantes HTTP antes de que lleguen al recurso, como una página JSP, un servlet o una página estática simple; De la misma manera, es posible administrar la respuesta de salida HTTP después de la ejecución del recurso.
Interceptor : los interceptores de Spring son similares a los filtros de servlet pero actúan en el contexto de Spring, por lo que son muchos poderosos para administrar la solicitud y respuesta HTTP, pero pueden implementar un comportamiento más sofisticado porque pueden acceder a todo el contexto de Spring.
Un HandlerInterceptor le brinda un control más detallado que un filtro, porque tiene acceso al "controlador" de destino real; esto significa que cualquier acción que realice puede variar según lo que esté haciendo la solicitud (mientras que el filtro de servlet se aplica genéricamente a todas las solicitudes, solo se pueden tener en cuenta los parámetros de cada solicitud). HandlerInterceptor también proporciona 3 métodos diferentes, por lo que puede aplicar el comportamiento antes de llamar a un controlador, después de que el controlador se haya completado pero antes de ver la representación (donde incluso puede omitir la representación de la vista por completo), o después de que la vista misma se haya representado. Además, puede configurar diferentes interceptores para diferentes grupos de manejadores; los interceptores se configuran en el handlerMapping y puede haber varios handlerMappings.
Por lo tanto, si tiene la necesidad de hacer algo completamente genérico (por ejemplo, registrar todas las solicitudes), entonces un filtro es suficiente, pero si el comportamiento depende del controlador de destino o si desea hacer algo entre el manejo de la solicitud y la representación de la vista, entonces el HandlerInterceptor proporciona esa flexibilidad.
Referencia: http://static.springframework.org/sp...ng-interceptor