This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
From java docs: protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException Part os the method description says: The GET method should also be idempotent, meaning that it can be safely repeated. Sometimes making a method safe also makes it idempotent. For example, repeating queries is both safe and idempotent, but buying a product online or modifying data is neither safe nor idempotent. What happens if you do have some code in the doGet(,) method that modifies data? Does the container consider the request as a "Bad request"?' Thx,
The servlet specification does not obligate the container to check if any data have been changed in the course of servicing a GET reqyuest. Thus it is the programmer's responsibility alone to ensure that a doGet() method is idempotent.
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
Hi Michael, Need a clarification on the implication of the doGet method being idempotent. When we say that repeated GET requests for the same URL should return the same respone, does the URL include the querystring too? Or is it that irrespective of the query string too the response should be the same? Thanks, GSS
SCJP, SCJD, SCWCD 1.3, SCWCD 1.4, SCBCD
Joined: Oct 09, 2003
For a particular query string, the response remains the same over multiple requests. So if a query string changes, the response changes, but will not change for the same query. So a GET request is NOT supposed to change state on the server, but the container is(will) not preventing it. Correct me if I am wrong. Thx,
Well said, Shreyas! The idea of idempotency gets stretched a little in practice. In short, one query should produce one result. Another way of saying this is the the query itself should not cause an unexpected state or behavior change. It's hard to come up with good examples. A very weak example is something like a hit counter. You could argue that hit counters are not idempotent, but because this behavior is expected and consistent, we don't think of idempotency as being relevant. A more radical illustration: every time sometimes GETs a certain web page on the tenth minute of the hour, say, the hosting server triggers a process to clear all current connections to the database. Clearly, that's not idempotent. It doesn't matter if the behavior is intended or accidental. When a method is idempotent, in short, you are guaranteeing that regardless of when or how often it's used, no "side effects" will occur. Sometimes this is a tougher standard to meet than you might think, especially when you have code running to create some or all of a web page's content.