RequestDispatcher.forward () vs HttpServletResponse.sendRedirect ()

¿Cuál es la diferencia conceptual entre forward()y sendRedirect()?

requestDispatcher - método forward ()

1. Cuando usamos el forwardmétodo, la solicitud se transfiere a otro recurso dentro del mismo servidor para su posterior procesamiento.

2. En el caso de forward, el contenedor web maneja todo el procesamiento interno y el cliente o navegador no está involucrado.

3. Cuando forwardse llama al requestDispatcherobjeto, pasamos los objetos de solicitud y respuesta, por lo que nuestro antiguo objeto de solicitud está presente en el nuevo recurso que procesará nuestra solicitud.

4. Visualmente, no podemos ver la dirección reenviada, es transparente.

5. Usar el forward()método es más rápido que sendRedirect.

6. Cuando redirigimos usando el reenvío, y queremos usar los mismos datos en un nuevo recurso, podemos usarlo request.setAttribute()ya que tenemos un objeto de solicitud disponible.

SendRedirect

1. En caso de que sendRedirectla solicitud se transfiera a otro recurso, a un dominio diferente o a un servidor diferente para su posterior procesamiento.

2. Cuando lo usa sendRedirect, el contenedor transfiere la solicitud al cliente o al navegador, por lo que la URL proporcionada dentro del sendRedirectmétodo es visible como una nueva solicitud para el cliente.

3. En caso de sendRedirectllamada, los objetos antiguos de solicitud y respuesta se pierden porque el navegador lo trata como una nueva solicitud.

4. En la barra de direcciones, podemos ver la nueva dirección redirigida. No es transparente

5. sendRedirectes más lento porque se requiere un viaje de ida y vuelta adicional, porque se crea una solicitud completamente nueva y se pierde el objeto de solicitud anterior. Se requieren dos solicitudes de navegador.

6. Pero sendRedirect, si queremos usar los mismos datos para un nuevo recurso, tenemos que almacenar los datos en sesión o pasarlos junto con la URL.

¿Cual es bueno?

Depende del escenario para el que el método sea más útil.

Si desea que el control se transfiera a un nuevo servidor o contexto, y se trate como una tarea completamente nueva, entonces vamos por sendRedirect. En general, se debe utilizar un reenvío si la operación se puede repetir de forma segura al volver a cargar el navegador en la página web y no afecta el resultado.

Fuente

En el mundo del desarrollo web, el término "redirigir" es el acto de enviar al cliente una respuesta HTTP vacía con solo un Locationencabezado que contiene la nueva URL a la que el cliente debe enviar una nueva solicitud GET. Así que básicamente:

• El cliente envía una solicitud HTTP a some.jsp.
• El servidor envía una respuesta HTTP con Location: other.jspencabezado
• El cliente envía una solicitud HTTP a other.jsp(¡esto se refleja en la barra de direcciones del navegador!)
• El servidor envía una respuesta HTTP con contenido de other.jsp.

Puede rastrearlo con el conjunto de herramientas de desarrollador incorporado / complemento del navegador web. Presione F12 en Chrome / IE9 / Firebug y verifique la sección "Red" para verlo.

Exactamente lo anterior se logra mediante sendRedirect("other.jsp"). El RequestDispatcher#forward()no envía una redirección. En su lugar, utiliza el contenido de la página de destino como respuesta HTTP.

• El cliente envía una solicitud HTTP a some.jsp.
• El servidor envía una respuesta HTTP con contenido de other.jsp.

Sin embargo, como era la solicitud HTTP original some.jsp, la URL en la barra de direcciones del navegador permanece sin cambios. Además, cualquier atributo de solicitud establecido en el controlador detrás some.jspestará disponible en other.jsp. Esto no sucede durante una redirección porque básicamente está obligando al cliente a crear una nueva solicitud HTTP other.jsp, some.jsprechazando la solicitud original al incluir todas sus atribuciones.

El RequestDispatcheres extremadamente útil en el paradigma MVC y / o cuando desea ocultar JSP del acceso directo. Puede colocar los JSP en la /WEB-INFcarpeta y usar uno Servletque controle, preprocese y postprocese las solicitudes. Las /WEB-INFURL no Servletpueden acceder directamente a los JSP de la carpeta, pero pueden acceder a ellos mediante RequestDispatcher#forward().

Puede, por ejemplo, tener un archivo JSP /WEB-INF/login.jspy uno LoginServletque esté mapeado en uno url-patternde /login. Cuando invoque http://example.com/context/login, se invocarán los servlets doGet(). Puede hacer cualquier procesamiento previo y finalmente reenviar la solicitud como:

request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);

Cuando envía un formulario, normalmente desea utilizar POST:

<form action="login" method="post">

De esta forma, doPost()se invocarán los servlets y podrá realizar cualquier tarea de procesamiento posterior (por ejemplo, validación, lógica de negocios, inicio de sesión del usuario, etc.).

Si hay algún error, normalmente desea reenviar la solicitud a la misma página y mostrar los errores al lado de los campos de entrada, etc. Puedes usar el RequestDispatcherpara esto.

Si a POSTtiene éxito, normalmente desea redirigir la solicitud, de modo que la solicitud no se vuelva a enviar cuando el usuario actualice la solicitud (por ejemplo, presionando F5 o volviendo al historial).

User user = userDAO.find(username, password);
if (user != null) {
    request.getSession().setAttribute("user", user); // Login user.
    response.sendRedirect("home"); // Redirects to http://example.com/context/home after succesful login.
} else {
    request.setAttribute("error", "Unknown login, please try again."); // Set error.
    request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to same page so that you can display error.
}

Una redirección le indica al cliente que active una nueva GETsolicitud en la URL dada. Actualizar la solicitud solo actualizaría la solicitud redirigida y no la solicitud inicial. Esto evitará "envíos dobles" y confusión y malas experiencias de usuario. Esto también se llama POST-Redirect-GETpatrón .

Ver también:

• ¿Cómo funcionan los servlets? Instanciación, sesiones, variables compartidas y subprocesos múltiples
• doGet y doPost en servlets
• ¿Cómo realizar la validación y mostrar el mensaje de error en la misma forma en JSP?
• HttpServletResponse sendRedirect permanente

La RequestDispatcherinterfaz le permite hacer un servidor hacia adelante / incluir mientras que sendRedirect()hace un redireccionamiento del lado del cliente. En una redirección del lado del cliente, el servidor enviará un código de estado HTTP de 302(redirección temporal) que hace que el navegador web emita una nueva GETsolicitud HTTP para el contenido en la ubicación redirigida. En contraste, cuando se usa la RequestDispatcherinterfaz, la inclusión / reenvío al nuevo recurso se maneja completamente en el lado del servidor.

La principal diferencia importante entre el método forward () y sendRedirect () es que en el caso de forward (), la redirección ocurre en el extremo del servidor y no es visible para el cliente, pero en el caso de sendRedirect (), la redirección ocurre en el extremo del cliente y es visible al cliente

Cualquiera de estos métodos puede ser "mejor", es decir, más adecuado, dependiendo de lo que desee hacer.

Una redirección del lado del servidor es más rápida en la medida en que obtiene los datos de una página diferente sin realizar un viaje de ida y vuelta al navegador. Pero la URL que se ve en el navegador sigue siendo la dirección original, por lo que está creando una pequeña inconsistencia allí.

Una redirección del lado del cliente es más versátil en la medida en que puede enviarlo a un servidor completamente diferente, o cambiar el protocolo (por ejemplo, de HTTP a HTTPS), o ambos. Y el navegador conoce la nueva URL. Pero se necesita un intercambio adicional entre el servidor y el cliente.

SendRedirect()buscará el contenido entre los servidores. es lento porque tiene que intimar el navegador enviando la URL del contenido. entonces el navegador creará una nueva solicitud para el contenido dentro del mismo servidor o en otro.

RquestDispatcheres para buscar el contenido dentro del servidor, creo. es el proceso del lado del servidor y es más rápido en comparación con el SendRedirect()método. pero la cuestión es que no intimará al navegador en el servidor en el que está buscando la fecha o el contenido requeridos, ni le pedirá al navegador que cambie la URL en la pestaña URL. por lo que causa pocos inconvenientes al usuario.

Técnicamente, se debe utilizar la redirección si necesitamos transferir el control a un dominio diferente o lograr la separación de la tarea.

Por ejemplo, en la aplicación de pago hacemos primero el PaymentProcess y luego redirigimos a displayPaymentInfo. Si el cliente actualiza el navegador, solo displayPaymentInfo se volverá a hacer y PaymentProcess no se repetirá. Pero si utilizamos reenviar en este escenario, tanto PaymentProcess como displayPaymentInfo se volverán a ejecutar de forma secuencial, lo que puede generar datos incosistentes.

Para otros escenarios, el reenvío es eficiente de usar ya que es más rápido que sendRedirect

Request Dispatcher es una interfaz que se utiliza para enviar la solicitud o respuesta del recurso web al otro recurso web. Contiene principalmente dos métodos.

1. request.forward(req,res): Este método se utiliza para reenviar la solicitud de un recurso web a otro recurso. es decir, de un servlet a otro servlet o de una aplicación web a otra aplicación web.

2. response.include(req,res): Este método se utiliza incluye la respuesta de un servlet a otro servlet

NOTA: AL utilizar el Despachador de solicitudes podemos reenviar o incluir la solicitud o las respuestas en el mismo servidor.

request.sendRedirect(): AL usar esto, podemos reenviar o incluir la solicitud o las respuestas en los diferentes servidores. En esto, el cliente obtiene una indicación al redirigir la página, pero en el proceso anterior, el cliente no obtendrá información

Simplemente diferencia entre Forward(ServletRequest request, ServletResponse response)y sendRedirect(String url)es

adelante():

1. El forward()método se ejecuta en el lado del servidor.
2. La solicitud se transfiere a otro recurso dentro del mismo servidor.
3. No depende del protocolo de solicitud del cliente, ya que el forward ()método lo proporciona el contenedor de servlets.
4. La solicitud es compartida por el recurso de destino.
5. Solo se consume una llamada en este método.
6. Se puede usar dentro del servidor.
7. No podemos ver el mensaje reenviado, es transparente.
8. El forward()método es más rápido que el sendRedirect()método.
9. Se declara en la RequestDispatcherinterfaz.

sendRedirect ():

1. El método sendRedirect () se ejecuta en el lado del cliente.
2. La solicitud se transfiere a otro recurso a un servidor diferente.
3. El método sendRedirect () se proporciona bajo HTTP, por lo que solo se puede usar con clientes HTTP.
4. Se crea una nueva solicitud para el recurso de destino.
5. Se consumen dos llamadas de solicitud y respuesta.
6. Se puede usar dentro y fuera del servidor.
7. Podemos ver la dirección redirigida, no es transparente.
8. El método sendRedirect () es más lento porque cuando se crea una nueva solicitud, se pierde el antiguo objeto de solicitud.
9. Se declara en HttpServletResponse.