Spring WebFlux, Al igual que Spring MVC, está diseñado en un patrón de punto único de entrada (controlador frontal), donde un WebHandler
central, DispatcherHandler
, proporciona el algoritmo general de procesamiento de solicitudes y el trabajo real. se realiza mediante componentes configurables -delegados. Este modelo es flexible y admite diferentes flujos de trabajo.
DispatcherHandler
descubre los beans delegados que necesita desde la configuración de Spring. También está diseñado para actuar como un Spring Bean e implementa ApplicationContextAware
para acceder al contexto en el que se está ejecutando. Si DispatcherHandler
se declara con el nombre de bean webHandler
, entonces, a su vez, lo descubre WebHttpHandlerBuilder
, que ensambla la cadena de procesamiento de solicitudes.
La configuración de Spring en una aplicación WebFlux generalmente contiene:
DispatcherHandler
con nombre de beanwebHandler;
WebFilter
yWebExceptionHandler
beans;-
DispatcherHandler beans
especial; Y más.
La configuración se pasa a WebHttpHandlerBuilder
para cofnstruir el procesamiento de la cadena como se muestra en el siguiente ejemplo:
ApplicationContext context = ...
HttpHandler handler = WebHttpHandlerBuilder.applicationContext(context).build();
val context: ApplicationContext = ...
val handler = WebHttpHandlerBuilder.applicationContext(context).build()
El HttpHandler
recibido está listo para usarse con el adaptador de servidor.
1.3.1. Tipos de beans especializados
DispatcherHandler
delega a beans especiales el procesamiento de solicitudes y la emisión de respuestas apropiadas. Por "beans especiales" nos referimos a instancias Object
administradas por Spring que implementan contratos marco WebFlux. Por lo general, tienen contratos integrados, pero puede personalizar sus propiedades, ampliarlas o reemplazarlas.
La siguiente tabla enumera los beans especiales que descubre DispatcherHandler
. Tenga en cuenta que también hay otros tipos de beans que se definen en un nivel inferior.
Tipo de frijol | Explicación |
---|---|
|
Asigna una solicitud de controlador. La asignación se basa en algunos criterios, cuyos detalles dependen de la implementación de
|
|
Ayuda a |
|
Procesa el resultado de la llamada del controlador y completa la respuesta. |
Configuración de WebFlux
Las aplicaciones pueden declarar beans de infraestructura necesarios para procesar solicitudes. Sin embargo, en la mayoría de los casos la configuración de WebFlux es el mejor punto de partida. Declara los beans necesarios y proporciona una API de devolución de llamada de configuración de nivel superior para la configuración.
1.3.3. Manejo
DispatcherHandler
procesa las solicitudes de la siguiente manera:
A cada
HandlerMapping
se le pide que encuentre un controlador adecuado y se utiliza la primera coincidencia.Si se encuentra un controlador, se ejecuta a través del
HandlerAdapter
correspondiente, que expone el valor de retorno después de la ejecución comoHandlerResult
.HandlerResult
se pasa alHandlerResultHandler
correspondiente para completar el procesamiento escribiendo en la respuesta directamente o usando una vista de renderizado.
1.3.4. Procesando los resultados
El valor de retorno después de llamar al controlador a través de HandlerAdapter
se empaqueta como un HandlerResult
, junto con algún contexto adicional, y se pasa al primer HandlerResultHandler
, que contiene una declaración sobre su soporte. La siguiente tabla muestra las implementaciones disponibles de HandlerResultHandler
, todas las cuales están declaradas en la configuración de WebFlux:
Tipo de controlador de resultados | Valores de retorno | Orden predeterminado |
---|---|---|
|
|
0 |
|
|
0 |
|
Procesar valores de retorno de métodos marcados con la anotación |
100 |
|
|
|
Excepciones
ElHandlerResult
devuelto por HandlerAdapter
puede exponer una función para el manejo de errores basado en algún mecanismo específico del controlador. Esta función de error se llama si:
Falla una llamada a un controlador (por ejemplo, la anotación
@Controller
).El procesamiento del valor de retorno del controlador a través de
HandlerResultHandler
falla.
La función de error puede cambiar la respuesta (por ejemplo, a el estado de error), siempre que la señal de error ocurra antes de que el tipo reactivo devuelto por el controlador produzca cualquier elemento de datos.
Métodos anotados con @ExceptionHandler
en clases anotadas con @Controller
son compatibles de esta manera. Por el contrario, su soporte en Spring MVC se basa en HandlerExceptionResolver
. Normalmente esto no importa. Sin embargo, tenga en cuenta que WebFlux no puede usar la anotación @ControllerAdvice
para manejar excepciones que ocurren antes de que se seleccione el controlador.
Ver: Consulte también la subsección "Gestión de excepciones" en la sección "Controlador anotado" o la subsección "Excepciones" en la sección API WebHandler.
Reconocimiento de vistas
El reconocimiento de vistas permite la representación en el navegador usando plantilla y modelo HTML, sin vincularlo a una tecnología de presentación específica. En Spring WebFlux, el reconocimiento de vistas es compatible con un HandlerResultHandler especial que utiliza instancias ViewResolver
para asignar una cadena (que representa el nombre lógico de la vista) a una instancia View
. Luego, View
se usa para representar la respuesta.
Procesamiento
ElHandlerResult
se pasa al ViewResolutionResultHandler
contiene el valor de retorno del controlador y un modelo que contiene los atributos agregados durante el procesamiento de la solicitud. El valor de retorno se trata como uno de los siguientes:
String
,CharSequence
: el nombre lógico de la vista que debería resolverse enView
a través de una lista de implementaciones configuradas deViewResolver
.void
: Selecciona el nombre de la vista predeterminada según la solicitud de ruta, menos la barra diagonal inicial y final, y se resuelve enView
. Lo mismo sucede si no se especificó ningún nombre de vista (por ejemplo, se devolvió un atributo de modelo) o hay un valor de retorno asincrónico (por ejemplo,Mono
terminó vacío).Renderizado: API para scripts de reconocimiento de vistas. Explore las capacidades de su IDE completando código.
Model
,Map
: atributos de modelo adicionales que se deben agregar a modelo para la solicitud.Cualquier otro: cualquier otro valor de retorno (que no sean los tipos simples definidos por BeanUtils#isSimpleProperty) se considera un atributo del modelo que se debe agregar al modelo. El nombre del atributo se infiere del nombre de la clase usando el destino convenciones si falta la anotación del método del controlador
@ModelAttribute
.
El modelo puede contener tipos reactivos asíncronos (por ejemplo, de Reactor o RxJava). Antes de renderizar, AbstractView
resuelve dichos atributos del modelo en valores concretos y actualiza el modelo. Los tipos reactivos de un solo valor se resuelven en un solo valor o ningún valor (si está vacío), y los tipos reactivos de múltiples valores (como Flux<T>
) se recopilan y resuelven en List<T>
.
Configurar el reconocimiento de vistas es tan simple como agregar el bean ViewResolutionResultHandler
a su configuración de Spring. La configuración de WebFlux proporciona una API de configuración dedicada para reconocer vistas.
Redirección
El prefijo especial redirect:
en el nombre de la vista permite la redirección. UrlBasedViewResolver
(y subclases) reconoce esto como una indicación de que se requiere una redirección. El resto del nombre de la vista es la URL de redireccionamiento.
El resultado neto es el mismo que si el controlador hubiera devuelto RedirectView
o Rendering.redirectTo("abc").build()
, pero ahora el propio controlador puede operar con nombres de vistas lógicas. Un nombre de vista como redirect:/some/resource
es específico de la aplicación actual, mientras que un nombre de vista como redirect:https://example.com/arbitrary/path
, redirige a una URL absoluta.
Negociación de contenido
ViewResolutionResultHandler
admite la negociación de contenido. Este controlador compara los tipos de medios de la solicitud con los tipos de medios admitidos por cada View
seleccionada. Se utiliza la primera View
que admite los tipos de medios solicitados.
Para admitir tipos de medios como JSON y XML, Spring WebFlux proporciona un HttpMessageWriterView
, que es una View
especial que se representa a través de un HttpMessageWriter. Normalmente, estas vistas se configuran como vistas predeterminadas a través de la configuración de WebFlux. Las vistas predeterminadas siempre se seleccionan y utilizan si coinciden con el tipo de medio solicitado.
GO TO FULL VERSION