difference between forwarding and redirection [duplicate] - java

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
difference between jsp forward and redirect
Does anyone knows the differences between forwarding and redirection in Http servlets and the impact of these differences on browser refreshes?

forwarding is done without letting client know that, It is used to do internal communication at server, while in redirecting we are asking client go back and ask it over here.
Real life example
Forwarding
You went to postoffice there are number of boxes and person sitting there, now one of them accepts your request and it internally forwards it to other responsible person to fulfil your request and at the end of the process you will get the result
Redirecting
now the same person gives you a token which says goto window no5 and ask that person .
Also See
difference-between-jsp-forward-and-redirect

Read this wikipedia article, which explains it very clearly.
A forward just transfers the responsibility of a single request handling to a new server-dide component (example: servlet --> JSP). A redirect asks the browser to send a new request when a first one has been partially handled (example :create product --> redirect to list of products).
The post-redirect-get pattern, which is explained in the wikipedia article, explains when and why a redirect is preferrable.

fowarding happens on the server side. the server fowards a request to some other page and let that page handle it.
redirection plays between server and client. the server return some HTTP code (dont have in mind now) to the client which tells him the make a new GET request for the page redirected to, this happens without any user interaction.

Forward is transparent to the browser.
Redirect is not. It involves the browser loading a second URL. So I'd assume this is a bit slower.
See here for more info

Related

Which HTTP method to use for this client request?

I am developing a REST web service in Java which on clients' request processes the request body and gives the output to the client. The request body sent by the client consists of a GO(programing language) program which the server executes(runs) on the server machine and returns the standard output of the program back to the client. Now since the request body contains some text(program), I cannot use HTTP GET method to do that. I can use PUT or POST, but I have learnt that they(PUT and POST) are generally used for updating/creating a resource. Since, I am not creating any resource here, is it conceptually correct to use PUT or POST. If not, which is the HTTP method that I need to use?
Looking at the problem you are solving and comparing to an existing production solution , I suggest that you can use POST in your scenario.
Reasoning - Example Production code solving similar problem:-
Assuming that the problem you are trying to solve is this:-
Clients submit code in Go programming language, Your server compiles it, runs it and then gives the output. Assuming also that, it is somewhat similar to many online coding websites like hackerEarth, their API documentation page and the sample python code provided show that we can use HTTP:POST to submit code to the server for its processing.
Reasoning - RFC for HTTP POST, PUT :-
POST is designed to allow a uniform method to cover the following functions:
Providing a block of data, such as the result of submitting a
form, to a data-handling process;
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.
Referring to the above statements, we can conclude that in the context of this problem which you are solving, you are requesting the server to do some data-handling for the enclosed entity, so you can use POST.

sendRedirect VS requestDispatcher.forward for error page?

So there is an error.jsp page and I want user to occur on this page after he/she inputs invalid data.
Is it better to use sendRedirect or requestDispatcher.forward for redirecting to the error page?
I know, it may depend on whether I want to put some attributes to the request object and so on. And I'd prefer to use requestDispatcher.forward, but is it safe? Cause in this case after page refreshing the data will be sent to the server one more time. Yeah, it doesn't make any effect (insert, update, delete) on database since the data is invalid so the user occurs at the error page once again. But... idk, I feel like something is being wrong with the approach of using requestDispatcher.forward, even though it's kind of idempotent action.
So what do you think?
The important difference is :
The function sendRedirect will send a 302 response code to browser, then the browser will send another request to server again
https://en.wikipedia.org/wiki/HTTP_302
but the function requestDispatcher.forward is a server internal redirection, The browser has no feeling about it !

Can a sub resource change its "parent" resource in REST?

If I do a POST to /quizzes/1/answer/final I want the answer to be saved on the server, but I also want to set a submitted date on the quiz resource as well as update the status of the quiz to done. Can I do that when I POST to the URI mentioned or should I do another request where I update the quiz-resource?
Since I want the workflow to be on the server, I don't want the client to do to much, but I don't know if changing another resource when I am posting an answer is right either?
What should I respond with from this POST?
Should I respond with the answer and a 20x, a 303 pointing to the answer, a 303 pointing to the quiz etc?
Ultimately the transitions of state on your server and your response resources are up to you and your requirements. REST is only a guide.
I personally agree that if the state of the quiz resource should change with a particular action I would do so, as you then save a RTT and client complexity.
Edit to add: Also when writing any service, I start with the assumption that the client will lie to me. If the client is responsible for submitting the answer then appropriately updating the quiz, what's to stop a client from submitting an answer and then setting the time of the quiz to 30 years ago or a thousand years in the future?
As far as a successful response from the POST, I think it would depend on what should the client do next. If they might want to go either direction an option could be a 200 with the submitted answer (the resource at the current uri, as a confirmation), and canonical links to the answer and a link to the overall quiz. I would lean toward 200 as it clearly indicates success, however that is an opinion, and again how would your intended client behave. (Is it a browser or a programmatic client or both? That might influence your decision)

Applet -> servlet -> another applet communication

I'm implementing a simple checkers game (java applets as clients + servlet) where two players can connect to the servlet and play. As I'm just beginning with applet-servlet programming, I have some problems with the proper communication.
Let's suppose the game begins and first player moves. Then I have to send his move to the servlet which should inform the other player. And here I don't know how to do that. How the servlet can pass received data to another applet, not the one that sent it? How and where should the servlet keep the info related to players so that it can recognize which one sent the data?
Fisrt: the servlet won't pass data or message to any servlet from its initiative.
It will have to wait for the applet to send a request, and then will be able to send a proper response.
So, the simplest seems that your applets regularly send requests to the servlet, like "what's up?". It's the polling system ome is talking about.
To recognize which player is polling, give them an id when they first access your servlet (register ?), and make that id present in every future request.
Is that clear enough ? :)
(and yes, next step is to use COMET)

sendRedirect or request Dispatch is more efficient?

SendRedirect or requestdispatch ?Which should be more preferred?Which is more efficient?
They do two very different things, so you cannot just decide on efficiency.
Sending a redirect will send the browser to a different URL. That URL will be visible to the browser. You may or may not want that. For example, after a POST, you should probably redirect to a GET page to avoid that the result page cannot be reloaded without re-posting. On the other hand, you cannot redirect to "pages" that are only accessible from inside the servlet container.
A dispatch is more "efficient" in that there is no extra round-trip, but it only works withing the same web-application context (or at most within the same servlet container if you so set it up). Also, the URL that the user used to access the page in the first place will be different from what a servlet later on in the chain will be called as, which may be confusing. The dispatch pattern is often used for extra processing before or after the real request (in lieu of a ServletFilter), or for error pages.
You can pass along request attributes using a dispatch, but only query parameters on a redirect. You cannot redirect as a POST (so the amount of data that you can attach to it is limited). All query parameters in a redirect are visible to the user.
It forward is efficient to use since as it is faster than sendRedirect,redirect should be used if we need to transfer control to different domain.
When we invoke a forward request, the request is sent to another resource on the server, without the client being informed that a different resource is going to process the request. This process occurs completely with in the web container.
On the other hand when a sendRedirect method is invoked, it causes the web container to return to the browser indicating that a new URL should be requested.
Because the browser issues a completely new request any object that are stored as request attributes before the redirect occurs will be lost.
This extra round trip makes redirect slower than forward.

Categories