RequestDispatcher.forward () contre HttpServletResponse.sendRedirect ()

Quelle est la différence conceptuelle entre forward()et sendRedirect()?

requestDispatcher - méthode forward ()

1. Lorsque nous utilisons la forwardméthode, la demande est transférée vers une autre ressource du même serveur pour un traitement ultérieur.

2. Dans le cas de forward, le conteneur Web gère tout le traitement en interne et le client ou le navigateur n'est pas impliqué.

3. Quand forwardest appelé sur l' requestDispatcherobjet, nous passons les objets de requête et de réponse, donc notre ancien objet de requête est présent sur la nouvelle ressource qui va traiter notre requête.

4. Visuellement, nous ne pouvons pas voir l'adresse transmise, elle est transparente.

5. L'utilisation de la forward()méthode est plus rapide que sendRedirect.

6. Lorsque nous redirigeons en utilisant forward et que nous voulons utiliser les mêmes données dans une nouvelle ressource, nous pouvons utiliser request.setAttribute()car nous avons un objet de requête disponible.

EnvoyerRedirect

1. Dans ce cas sendRedirect, la demande est transférée vers une autre ressource, vers un domaine différent ou vers un serveur différent pour un traitement ultérieur.

2. Lorsque vous utilisez sendRedirect, le conteneur transfère la demande au client ou au navigateur, de sorte que l'URL donnée dans la sendRedirectméthode est visible en tant que nouvelle demande au client.

3. En cas d' sendRedirectappel, les anciens objets de requête et de réponse sont perdus car ils sont traités comme une nouvelle requête par le navigateur.

4. Dans la barre d'adresse, nous pouvons voir la nouvelle adresse redirigée. Ce n'est pas transparent.

5. sendRedirectest plus lent car un aller-retour supplémentaire est nécessaire, car une demande complètement nouvelle est créée et l'ancien objet de demande est perdu. Deux requêtes de navigateur sont requises.

6. Mais dans sendRedirect, si nous voulons utiliser les mêmes données pour une nouvelle ressource, nous devons stocker les données en session ou les transmettre avec l'URL.

Lequel est bon?

Cela dépend du scénario pour lequel la méthode est la plus utile.

Si vous voulez que le contrôle soit transféré vers un nouveau serveur ou contexte, et que cela soit traité comme une tâche complètement nouvelle, alors nous y allons sendRedirect. En règle générale, un transfert doit être utilisé si l'opération peut être répétée en toute sécurité lors d'un rechargement de la page Web par le navigateur et n'affectera pas le résultat.

La source

Dans le monde du développement Web, le terme «redirection» est le fait d'envoyer au client une réponse HTTP vide avec juste un en- Locationtête contenant la nouvelle URL à laquelle le client doit envoyer une toute nouvelle requête GET. Donc en gros:

• Le client envoie une requête HTTP à some.jsp.
• Le serveur renvoie une réponse HTTP avec en- Location: other.jsptête
• Le client envoie une requête HTTP à other.jsp(cela se reflète dans la barre d'adresse du navigateur!)
• Le serveur renvoie une réponse HTTP avec le contenu de other.jsp.

Vous pouvez le suivre avec l'ensemble d'outils de développement intégré / complémentaire du navigateur Web. Appuyez sur F12 dans Chrome / IE9 / Firebug et vérifiez la section "Réseau" pour le voir.

Exactement ce qui précède est réalisé par sendRedirect("other.jsp"). Le RequestDispatcher#forward()n'envoie pas de redirection. Au lieu de cela, il utilise le contenu de la page cible comme réponse HTTP.

• Le client envoie une requête HTTP à some.jsp.
• Le serveur renvoie une réponse HTTP avec le contenu de other.jsp.

Cependant, comme la requête HTTP d'origine l'était some.jsp, l'URL dans la barre d'adresse du navigateur reste inchangée. De plus, tous les attributs de requête définis dans le contrôleur derrière some.jspseront disponibles dans other.jsp. Cela ne se produit pas lors d'une redirection car vous forcez essentiellement le client à créer une nouvelle requête HTTP other.jsp, rejetant ainsi la requête d'origine en some.jspincluant tous ses attributs.

Le RequestDispatcherest extrêmement utile dans le paradigme MVC et / ou lorsque vous souhaitez masquer les JSP de l'accès direct. Vous pouvez placer les JSP dans le /WEB-INFdossier et utiliser un Servletqui contrôle, pré-traite et post-traite les requêtes. Les JSP du /WEB-INFdossier ne sont pas directement accessibles par URL, mais Servletpeuvent y accéder en utilisant RequestDispatcher#forward().

Vous pouvez par exemple avoir un fichier JSP dans /WEB-INF/login.jspet un LoginServletqui est mappé sur un url-patternde /login. Lorsque vous invoquez http://example.com/context/login, le servlet doGet()sera appelé. Vous pouvez faire n'importe quel pré- traitement là-dedans et enfin transmettre la demande comme:

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

Lorsque vous soumettez un formulaire, vous souhaitez normalement utiliser POST:

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

De cette façon, les servlets doPost()seront invoqués et vous pourrez y effectuer n'importe quel post- traitement (par exemple, validation, logique métier, connexion de l'utilisateur, etc.).

S'il y a des erreurs, vous souhaitez normalement renvoyer la demande à la même page et afficher les erreurs à côté des champs de saisie, etc. Vous pouvez utiliser le RequestDispatcherpour cela.

Si a POSTréussit, vous voulez normalement rediriger la demande, de sorte que la demande ne soit pas resoumise lorsque l'utilisateur actualise la demande (par exemple en appuyant sur F5 ou en revenant dans l'historique).

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.
}

Une redirection demande donc au client de lancer une nouvelle GETrequête sur l'URL donnée. L'actualisation de la demande actualiserait alors uniquement la demande redirigée et non la demande initiale. Cela évitera les «doubles soumissions», la confusion et les mauvaises expériences utilisateur. Ceci est également appelé le POST-Redirect-GETmodèle .

Voir également:

• Comment fonctionnent les servlets? Instanciation, sessions, variables partagées et multithreading
• doGet et doPost dans des servlets
• Comment effectuer la validation et afficher le message d'erreur sous la même forme dans JSP?
• HttpServletResponse sendRedirect permanent

L' RequestDispatcherinterface vous permet de faire une sendRedirect()redirection / inclusion côté serveur alors qu'une redirection côté client. Dans une redirection côté client, le serveur renverra un code d'état HTTP de 302(redirection temporaire) qui oblige le navigateur Web à émettre une toute nouvelle GETrequête HTTP pour le contenu à l'emplacement redirigé. En revanche, lors de l'utilisation de l' RequestDispatcherinterface, l'inclusion / transmission vers la nouvelle ressource est entièrement gérée côté serveur.

La principale différence importante entre les méthodes forward () et sendRedirect () est que dans le cas de forward (), la redirection se produit à l'extrémité du serveur et n'est pas visible pour le client, mais dans le cas de sendRedirect (), la redirection se produit à l'extrémité du client et elle est visible au client.

L'une ou l'autre de ces méthodes peut être «meilleure», c'est-à-dire plus appropriée, selon ce que vous voulez faire.

Une redirection côté serveur est plus rapide dans la mesure où vous obtenez les données d'une page différente sans faire un aller-retour vers le navigateur. Mais l'URL vue dans le navigateur est toujours l'adresse d'origine, vous créez donc une petite incohérence.

Une redirection côté client est plus polyvalente dans la mesure où elle peut vous envoyer vers un serveur complètement différent, ou changer le protocole (par exemple de HTTP à HTTPS), ou les deux. Et le navigateur est conscient de la nouvelle URL. Mais il faut un aller-retour supplémentaire entre le serveur et le client.

SendRedirect()recherchera le contenu entre les serveurs. il est lent car il doit intimer le navigateur en envoyant l'URL du contenu. alors le navigateur créera une nouvelle demande pour le contenu dans le même serveur ou dans un autre.

RquestDispatcherest pour rechercher le contenu dans le serveur, je pense. c'est le processus côté serveur et il est plus rapide que la SendRedirect()méthode. mais le fait est qu'il n'intimera pas le navigateur dans quel serveur il recherche la date ou le contenu requis, ni ne demandera au navigateur de modifier l'URL dans l'onglet URL. donc cela ne cause que peu d'inconvénients à l'utilisateur.

La redirection technique doit être utilisée si nous devons transférer le contrôle vers un domaine différent ou pour réaliser la séparation des tâches.

Par exemple, dans l'application de paiement, nous effectuons d'abord PaymentProcess, puis nous redirigeons vers displayPaymentInfo. Si le client actualise le navigateur, seul displayPaymentInfo sera refait et PaymentProcess ne sera pas répété. Mais si nous utilisons forward dans ce scénario, PaymentProcess et displayPaymentInfo seront réexécutés de manière séquentielle, ce qui peut entraîner des données incohérentes.

Pour d'autres scénarios, le transfert est efficace car il est plus rapide que sendRedirect

Request Dispatcher est une interface utilisée pour envoyer la demande ou la réponse d'une ressource Web à une autre ressource Web. Il contient principalement deux méthodes.

1. request.forward(req,res): Cette méthode est utilisée pour transmettre la demande d'une ressource Web à une autre ressource. c'est-à-dire d'une servlet à une autre servlet ou d'une application Web à une autre application Web.

2. response.include(req,res): Cette méthode est utilisée pour inclure la réponse d'un servlet à un autre servlet

REMARQUE: en utilisant Request Dispatcher, nous pouvons transférer ou inclure la demande ou les réponses dans le même serveur.

request.sendRedirect(): En utilisant cela, nous pouvons transférer ou inclure la demande ou les réponses sur les différents serveurs. Dans ce cas, le client reçoit une indication lors de la redirection de la page, mais dans le processus ci-dessus, le client ne recevra pas d'indication

Différence simplement entre Forward(ServletRequest request, ServletResponse response)et sendRedirect(String url)est

vers l'avant():

1. La forward()méthode est exécutée côté serveur.
2. La demande est le transfert vers une autre ressource au sein du même serveur.
3. Cela ne dépend pas du protocole de requête du client puisque la forward ()méthode est fournie par le conteneur de servlet.
4. La demande est partagée par la ressource cible.
5. Un seul appel est consommé dans cette méthode.
6. Il peut être utilisé dans le serveur.
7. Nous ne pouvons pas voir le message transmis, il est transparent.
8. La forward()méthode est plus rapide que la sendRedirect()méthode.
9. Il est déclaré dans l' RequestDispatcherinterface.

sendRedirect ():

1. La méthode sendRedirect () est exécutée côté client.
2. La demande est le transfert vers une autre ressource vers un serveur différent.
3. La méthode sendRedirect () est fournie sous HTTP et ne peut donc être utilisée qu'avec des clients HTTP.
4. Une nouvelle demande est créée pour la ressource de destination.
5. Deux appels de demande et de réponse sont consommés.
6. Il peut être utilisé à l'intérieur et à l'extérieur du serveur.
7. On peut voir l'adresse redirigée, ce n'est pas transparent.
8. La méthode sendRedirect () est plus lente car lors de la création d'une nouvelle requête, l'ancien objet de requête est perdu.
9. Il est déclaré dans HttpServletResponse.