Was ist der konzeptionelle Unterschied zwischen forward()
und sendRedirect()
?
requestDispatcher - forward () Methode
Wenn wir die Methode
forward
verwenden, wird die Anforderung zur weiteren Verarbeitung an eine andere Ressource auf demselben Server übertragen.Im Fall von
forward
wickelt der Webcontainer die gesamte Verarbeitung intern ab und der Client oder Browser ist nicht beteiligt.Wenn
forward
für dasrequestDispatcher
Objekt aufgerufen wird, übergeben wir die Anforderungs- und Antwortobjekte, sodass unser altes Anforderungsobjekt in der neuen Ressource vorhanden ist, die unsere Anforderung verarbeiten wird.Visuell können wir die weitergeleitete Adresse nicht sehen, sie ist transparent.
Die Verwendung der Methode
forward()
ist schneller alssendRedirect
.Wenn wir mit forward umleiten und dieselben Daten in einer neuen Ressource verwenden möchten, können wir
request.setAttribute()
verwenden, da uns ein Anforderungsobjekt zur Verfügung steht.SendRedirect
Im Fall von
sendRedirect
wird die Anforderung zur weiteren Verarbeitung an eine andere Ressource, eine andere Domäne oder einen anderen Server übertragen.Wenn Sie
sendRedirect
verwenden, überträgt der Container die Anforderung an den Client oder Browser, sodass die in der MethodesendRedirect
angegebene URL für den Client als neue Anforderung sichtbar ist.Beim Aufruf von
sendRedirect
gehen die alten Anfrage- und Antwortobjekte verloren, da sie vom Browser als neue Anfrage behandelt werden.In der Adressleiste sehen wir die neue umgeleitete Adresse. Es ist nicht transparent.
sendRedirect
ist langsamer, weil ein zusätzlicher Roundtrip erforderlich ist, weil eine vollständig neue Anforderung erstellt wird und das alte Anforderungsobjekt verloren geht. Es sind zwei Browseranforderungen erforderlich.Wenn wir jedoch in
sendRedirect
verwenden möchten, müssen wir die Daten in der Sitzung speichern oder zusammen mit der URL weitergeben.Welches ist gut?
Dies hängt vom Szenario ab, für das die Methode nützlicher ist.
Wenn Sie möchten, dass die Steuerung auf einen neuen Server oder Kontext übertragen wird und diese als völlig neue Aufgabe behandelt wird, gehen wir zu
sendRedirect
. Im Allgemeinen sollte eine Weiterleitung verwendet werden, wenn der Vorgang beim erneuten Laden der Webseite durch einen Browser sicher wiederholt werden kann und das Ergebnis nicht beeinträchtigt.
In der Welt der Webentwicklung ist der Begriff "Weiterleiten" der Vorgang, bei dem dem Client eine leere HTTP-Antwort mit nur einem Location
-Header gesendet wird, der die neue URL enthält, an die der Client eine brandneue GET-Anfrage senden muss. Also im Wesentlichen:
some.jsp
.Location: other.jsp
Zurückother.jsp
(Dies wird in der Adressleiste des Browsers angezeigt!)other.jsp
Zurück.Sie können dies mit dem im Webbrowser integrierten/hinzugefügten Entwickler-Toolset nachverfolgen. Drücken Sie F12 in Chrome/IE9/Firebug und überprüfen Sie den Abschnitt "Netzwerk", um es zu sehen.
Genau das oben Genannte wird durch sendRedirect("other.jsp")
erreicht. Die RequestDispatcher#forward()
sendet keine Umleitung. Stattdessen wird der Inhalt der Zielseite als HTTP-Antwort verwendet.
some.jsp
.other.jsp
Zurück.Da die ursprüngliche HTTP-Anforderung jedoch some.jsp
Lautete, bleibt die URL in der Adressleiste des Browsers unverändert.
Das RequestDispatcher
ist äußerst nützlich im MVC-Paradigma und/oder wenn Sie JSPs vor dem direkten Zugriff verbergen möchten. Sie können JSPs in den Ordner /WEB-INF
Einfügen und ein Servlet
verwenden, das die Anforderungen steuert, vorverarbeitet und nachverarbeitet. Auf die JSPs im Ordner /WEB-INF
Kann nicht direkt über die URL zugegriffen werden, aber die Servlet
können mit RequestDispatcher#forward()
darauf zugreifen.
Sie können beispielsweise eine JSP-Datei in /WEB-INF/login.jsp
Und ein LoginServlet
haben, das auf einem url-pattern
Von /login
Abgebildet ist. Wenn Sie http://example.com/context/login
Aufrufen, wird das doGet()
des Servlets aufgerufen. Du kannst alles machen vorverarbeiten von Inhalten und schließlich Weiterleiten der Anfrage wie:
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);
Wenn Sie ein Formular einreichen, möchten Sie normalerweise POST
verwenden:
<form action="login" method="post">
Auf diese Weise wird das doPost()
des Servlets aufgerufen und Sie können jedes tun postverarbeiten von Inhalten (z. B. Validierung, Geschäftslogik, Anmelden des Benutzers usw.).
Wenn es Fehler gibt, möchten Sie normalerweise die Anfrage zurück auf dieselbe Seite weiterleiten und die Fehler dort neben den Eingabefeldern anzeigen und so weiter . Sie können hierfür das RequestDispatcher
verwenden.
Wenn ein POST
erfolgreich ist, möchten Sie die Anforderung normalerweise umleiten , damit die Anforderung beim Aktualisieren des Benutzers nicht erneut übermittelt wird die Anfrage (z. B. F5 drücken oder zurück in den Verlauf navigieren).
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.
}
Eine Umleitung weist den Client daher an, eine neue GET
-Anforderung für die angegebene URL auszulösen. Wenn Sie die Anforderung aktualisieren, wird nur die umgeleitete Anforderung und nicht die ursprüngliche Anforderung aktualisiert. Dies vermeidet "Doppeleinreichungen" und Verwirrung und schlechte Benutzererfahrungen. Dies wird auch als POST-Redirect-GET
- Muster bezeichnet.
Über die Schnittstelle RequestDispatcher
können Sie eine serverseitige Weiterleitung/Einbindung vornehmen, während sendRedirect()
eine clientseitige Weiterleitung vornimmt. Bei einer clientseitigen Umleitung sendet der Server den HTTP-Statuscode 302
(Temporäre Umleitung) zurück, wodurch der Webbrowser eine brandneue HTTP-Anforderung GET
für den Inhalt bei der Umleitung ausgibt Standort. Im Gegensatz dazu erfolgt bei Verwendung der Schnittstelle RequestDispatcher
die Weiterleitung an die neue Ressource vollständig auf der Serverseite.
SendRedirect()
durchsucht den Inhalt zwischen den Servern. Dies ist langsam, da der Browser durch Senden der URL des Inhalts darauf hingewiesen werden muss. Der Browser erstellt dann eine neue Anforderung für den Inhalt auf demselben oder einem anderen Server.
RquestDispatcher
ist für das Suchen des Inhalts innerhalb des Servers, den ich denke. Es ist der serverseitige Prozess und ist im Vergleich zur SendRedirect()
-Methode schneller. Die Sache ist jedoch, dass es den Browser nicht darauf hinweist, auf welchem Server er das erforderliche Datum oder den gewünschten Inhalt sucht, und den Browser auch nicht auffordert, die URL in der Registerkarte URL zu ändern. Dies verursacht für den Benutzer nur geringe Unannehmlichkeiten.
Jede dieser Methoden kann "besser" sein, d. H. Geeigneter, je nachdem, was Sie tun möchten.
Eine serverseitige Weiterleitung ist schneller, wenn Sie die Daten von einer anderen Seite abrufen, ohne einen Roundtrip zum Browser durchzuführen. Die im Browser angezeigte URL ist jedoch immer noch die ursprüngliche Adresse, sodass Sie dort eine kleine Inkonsistenz erzeugen.
Eine clientseitige Umleitung ist vielseitiger, da sie Sie an einen völlig anderen Server senden oder das Protokoll ändern kann (z. B. von HTTP zu HTTPS) oder beides. Und der Browser kennt die neue URL. Es ist jedoch ein zusätzliches Hin und Her zwischen Server und Client erforderlich.
Die technische Umleitung sollte entweder verwendet werden, wenn die Kontrolle auf eine andere Domäne übertragen werden muss oder um eine Aufgabentrennung zu erreichen.
Zum Beispiel führen wir in der Zahlungsanwendung zuerst den PaymentProcess aus und leiten dann zu displayPaymentInfo weiter. Wenn der Client den Browser aktualisiert, wird nur displayPaymentInfo erneut ausgeführt und PaymentProcess wird nicht wiederholt. Wenn Sie in diesem Szenario die Weiterleitung verwenden, werden sowohl PaymentProcess als auch displayPaymentInfo nacheinander erneut ausgeführt, was zu inkosistenten Daten führen kann.
In anderen Szenarien ist die Weiterleitung effizient, da sie schneller als sendRedirect ist
Der Dispatcher lässt zu, dass Anforderungsdaten von einem Servlet zu einem anderen Servlet übertragen werden. Die Alternative des Request Dispatchers ist "Send Redirect". Bei jeder neuen Anfrage wird "Send Redirect" an das Netzwerk zurückgesendet, wenn der Request Dispatcher im Server auftritt.
Beispiel
Servlet-Dispatcher In Java= Das Konzept des Request-Dispatchers wird an einem einfachen Beispiel erläutert. Betrachten Sie die Situation, in der drei Servlets mit den Namen servlet1, servlet2 und servlet3 vorliegen. Falls wir den Dispatcher nicht verwenden, wann immer wir Anfrage für Servlet1, Server übergibt Kontrolle an Servlet1, danach, wenn wir nach Servlet2 fragen, kehrt die Kontrolle von Servlet 1 zum Server zurück und wird an Servlet2 übergeben. In diesem Fall, wenn sich der Server in Indien befindet und Servlet aus Amerika angefordert wird, erfolgt die zweite Anfrage Es muss zurück zum Server (Indien) und zurück zum Servlet (Amerika) gehen. Diese Option ist nicht gut, wenn zwischen Anforderung und Antwort viel Verkehr herrscht. Lösung für dieses Problem ist der Dispatcher.
Servlet-Dispatcher In Java Wenn wir den Dispatcher innerhalb des Servers verwenden, wird die Steuerung von Servlet1 an Servlet2 übergeben, ohne zum Server zurückzukehren und ohne das Netzwerk einzubeziehen. Dieses Konzept wird auch als Servlet-Verkettung bezeichnet wird als Servlet-Verkettung bezeichnet, da wir eine Kette von Servlet-Anforderungen von Servlet1 zu Servlet2, Servlet2 zu Servlet3 erstellen und der Server Daten von Servlet3 abruft.
Datenübermittlung
Bei der Servlet-Verkettung wird nicht nur die Steuerung übergeben, sondern es werden auch Daten von einem Servlet zu einem anderen Servlet übertragen, was im Vergleich zur Sendeweiterleitung von großem Vorteil ist. Bei der Umleitung zum Senden ist jede Anfrage eine neue Anfrage, jedes Mal, wenn Sie neue Daten erhalten.
Bedenken Sie, dass Servlet1 einen Anforderungsparameter hat, der von Servlet3 ausgeführt werden sollte, dann können Daten von Servlet1 zu Servlet2 und danach von Servlet2 zu Servlet3 übertragen werden, sodass hier die Anforderung von einem Servlet zu einem anderen Servlet beibehalten wird.
Die Lebensdauer der Anforderung ist sehr kurz. Sobald wir eine Antwort erhalten, ist die Anforderung beendet. Hier kann die Lebensdauer der Anforderung von einem Servlet zum anderen beibehalten werden. Mit Hilfe dieser Funktion können wir die Aufgaben in viele Servlets aufteilen.
Nachteil
Der Dispatcher ist in der Regel effizient, aber bei großen Datenmengen oder wenn wir überhaupt keine Daten benötigen oder wenn wenig Datenverkehr besteht, können Sie die Weiterleitung effizient durchführen.
Der Request Dispatcher ist eine Schnittstelle, die zum Versenden der Anforderung oder Antwort von einer Webressource an eine andere Webressource verwendet wird. Es enthält hauptsächlich zwei Methoden.
request.forward(req,res)
: Diese Methode leitet die Anforderung von einer Webressource an eine andere Ressource weiter. von einem Servlet zu einem anderen Servlet oder von einer Webanwendung zu einer anderen Webanwendung.
response.include(req,res)
: Diese Methode wird verwendet, um die Antwort eines Servlets auf ein anderes Servlet einzuschließen
ANMERKUNG: Mithilfe von Request Dispatcher können wir die Anforderung oder die Antworten an denselben Server weiterleiten oder in diesen aufnehmen.
request.sendRedirect()
: Indem wir dies verwenden, können wir die Anfrage oder Antworten über die verschiedenen Server weiterleiten oder einschließen. In diesem Fall erhält der Client eine Andeutung, während er die Seite umleitet, aber in dem obigen Prozess erhält der Client keine Andeutung