Bienvenidos.
Vamos a comenzar una nueva sección sobre interceptores HTTP.
Para qué sirven?
Cómo lo podemos implementar en Spring casos de uso?
Bueno, y también qué tanta relación tiene con nuestros datos, con nuestra lógica negocio, con nuestra
aplicación?
Qué hace un interceptor?
Bueno, lo implementamos y son útiles cuando se recrea aplicar alguna tarea, alguna funcionalidad específica
para ciertas peticiones http.
Cada vez que se ejecuta un método handler de controlador que se encarga de manejar una petición http
se carga.
Este método se ejecuta y podemos envolver este método de ejecución con alguna tarea, algún proceso.
Pero esta tarea no tiene mucha relación directa con la lógica negocio.
Más bien es transversal.
Es para dar algún tipo de soporte.
Por ejemplo, para validar alguna información, validar datos o registrar datos en el Logger.
Manejar transacciones SQL demasiado.
Todo lo que autenticación.
Todo lo que es autorización.
En fin, básicamente validaciones o realizar algún tipo.
Cálculo también.
Por ejemplo, para sistemas de monitoreo o estadístico de nuestra aplicación.
Cuáles son nuestras visitas?
Cuáles son los usuarios que están utilizando la aplicación?
Desde dónde vienen la IP?
En fin, un montón de cosas que podemos registrar en alguna tabla en el log.
Bueno, este fragmento de código se pueden reutilizar, ya que no solamente se pueden aplicar o interceptar
en un método de controlador, sino también en varios controladores, en varios métodos.
Entonces envuelven con una al día, antes o después del método controlador.
Y es que tenemos un ejemplo visual.
Acá tenemos el controlador Font Controller o cualquiera puede ser cualquier controlador, incluso API,
rest o que carga con vista, da lo mismo, pero siempre se va a interceptar este código antes de invocar
el método del controlador que maneja la petición.
Por ejemplo, anotá con Conquest Mapping con post mapping, input mapping con Telehit Mapping en caso
de que estemos con API Rest y también después de ejecutar el método.
Y también hay un tercer evento o método de este interceptor que podemos implementar en una tarea.
Cuando finaliza el proceso completo, es decir, cuando se haya renderizado la vista o cuando se haya
entregado la respuesta al cliente.
Bueno, justamente esto cómo funciona un interceptor?
Cómo lo podemos implementar?
Bueno, a través de una interfaz de Sprint Handler Interceptor.
Pero también la podemos implementar heredando de una clase abstracta que se llama Handler Interceptor
Adapter, un adaptador e implementar alguno de estos métodos.
Bueno, son tres métodos que podemos implementar.
No es obligación implementarlo todos, solamente lo que necesitemos, pero lo más típico e implementar
el presante.
Es decir, antes de que se ejecute o se invoque el método de controlador y el post handler después de
que se haya invocado el método del controlador.
Por lo tanto, con el pre y el post envolvemos con alguna tarea de funcionalidad lo que hace nuestro
request el método controlador.
Bueno, de hecho todo lo que es principie Unity y todo lo que manejo de transacciones de base auto con
Spring con Spring Data JPA ya maneja este tipo de cosas.
Por ejemplo con Spring si que Unity ya tiene su propio interceptores que se encarga por debajo de manejar.
Por ejemplo, si el usuario está autenticado, si el usuario tiene permiso a ciertos recursos, la aplicación
en fin, ya realiza esas tareas están implementadas, aunque también lo podríamos hacer a mano y en
el caso de manejo de transacción.
Todo lo que comí el rollback también a través de interceptores y también con programación, orienta
aspectos que intercepta métodos del service.
Por ejemplo, ya maneja la transacción utilizando la notación transaccional.
Entonces también puedo manejar el comit el rollback en caso de error también lo podemos hacer con interceptores,
pero como digo ya viene implementado no necesario.
Y un tercer método After Complicarán, que cuando finaliza el proceso completo, cuando se carga la
vista y se renderiza esta vista en el navegador, me entrega un detalle el handler es un método que
retorna un boli, no ese true o false.
Bueno, si retorna true perfecto.
Continúa con la ejecución de controlador de forma normal y también si tiene más interceptores, continúa
con la ejecución en cadena de lo demás interceptores que está dentro del stack de interceptores de nuestra
aplicación.
Pero qué pasa si retorna false?
Bueno, obviamente no ejecuta el controlador menos su método.
Andrés finaliza proceso.
El Interceptor se encarga o se hace cargo del rico test y lo maneja, por ejemplo, redirigiendo hacia
otra ruta o cargar otra vista con algún mensaje, con alguna funcionalidad.
Bueno, lo típico.
Por ejemplo, cuando el usuario no tiene sesión y detecta que no está autenticado, bueno, el interceptor
o el filtro redirige hacia la página login para iniciar sesión, por poner un ejemplo o si el usuario
no tiene permiso.
Por ejemplo, un usuario está autenticado y tiene un rol usuario pero no admin y esta página o recurso
necesita ser administrador.
Bueno, entonces en vez de ejecutar el CRUD y DA permiso, lo que hace es redirigir a una vista con
un mensaje que diga por ejemplo, no tiene acceso o permiso a esta funcionalidad o acceso restringido,
por ejemplo.
Bien, pero el método ponja handler que se ejecuta o podemos implementar algo después de que se haya
invocado el método handler del controlador, alguna tarea, algún proceso justo después y retorna voy
y el after complicarán.
Cuando finaliza todo y se renderiza la vista, se carga en el navegador al usuario.
Pero recuerden, es muy importante que cualquier tarea o funcionalidad de nuestro interceptor tiene
que ser transversal a nuestra lógica negocio, a nuestra aplicación.
No tiene una relación directa, es solamente de apoyo.
Tal como explicaba para guardar cosas en el log, en la bitácora, validar sesiones de usuario, realizar
validaciones digoque tipo manejo, transacción, pero al final no está relacionado con otro dato de
forma directa.
Bien, vamos a implementar nuestro interceptor, nos vamos al hide.
Y para este ejemplo la idea es calcular cuánto se demora en cargar una página, es decir, cuánto se
demora en procesar el request, encargar el controlador con el método András en milisegundos.
Entonces un interceptor que calcule el tiempo transcurrido del request de la petición.
Vamos a usar el mismo proyecto Spring Boot Formulario que estamos usando la sesión anterior de formulario.
Bien, vamos a crear un РАМКАХ.
En la raíz del РАМКАХ principal en AP interceptores o interceptores, como queramos finalizar.
Vamos a crear nuestro interceptor, una clase común y corriente, como siempre.
Tiempo transcurrido, interceptor
finalizar.
Bien había explicado en la introducción que debe implementar la interfaz handler interceptor handler
se refiere a los métodos de controlador al mantener request
importamos y bueno, por acá click derecho sources sobrescribir o guerray por acá.
Y acá están los tres métodos.
After compli chón, post, handler post andele y Andrè S.
Después, después de que se haya ejecutado manejado el método controlador, el request y pre.
Antes bien, vamos a marcar solamente el pre y el post, nada más.
Oke?
Entonces, pre antes y post después, esto acá lo vamos a quitar.
Vamos a retornar Trum Trum por ahora.
Bueno, recuerden que cuando es thru, cuando retornamos expoliando thru continúa con la ejecución normal
de nuestra aplicación del controlador y de los demás interceptores.
Si retorna fols.
Falso, por ejemplo por alguna validación, el usuario, por poner un ejemplo, no está autenticado
o falló alguna validación que implementamos cualquier cosa.
Bueno, si es fols.
Termina con la ejecución y no continúa con el controlador ni tampoco con los demás interceptores.
Queda hasta acá nomás.
Y podemos implementar, por ejemplo, un re direct para redirigir a otra ruta o página que se encargue
de manejar este problema.
Por ejemplo, la página de login para iniciar sesión y esto lo dejamos como pait, nada más.
Ya iún interceptor también se puede anotar con component para que lo podamos inyectar después.
Bueno, después vamos a ver que lo podemos inyectar en una clase configuración para poder registrarlo
y configurarlo.
Entonces component.
Iniciando con mayúscula y listo.
Bien, entonces acá recibe el recuas el response en cada uno de los métodos, pero acá en el pre recibe
el método el jantes.
Por ejemplo, el objeto que representa el método del controlador que se está invocando, que se está
ejecutando.
Y acá tenemos toda la información del método, el nombre, los argumentos, las anotaciones, todo.
Y podemos trabajar en base a estos parámetros y por acá.
Bueno, también tiene el handler, el response, el recuerdo.
Por ejemplo, en ambos casos Rickles y el response para trabajar con la petición y la respuesta o tener
parámetros, asignar parámetros, redirigir con directo.
En fin, un montón de cosas.
Y además acá obtiene el model ANBU para pasar datos a la vista.
Por ejemplo, en nuestro caso vamos a pasar el tiempo calculado en que se demoró en ejecutar el recuas.
Lo pasamos a la vista y lo podemos mostrar, por ejemplo en nuestras plantillas, en el formulario,
en la página de detalle o resultado, o en cualquier parte de nuestra aplicación, en cualquier vista
o plantilla de nuestra aplicación.
Nada más.
Nos vemos en la siguiente clase.