And why is do-Get() method is non-idempotent ,if HTTP 1.1 GET method is idempotent ,it's not making any sense.???
Joined: Mar 22, 2005
It's the job of the developer to ensure that his/her code does not violate specifications. It's not like there's an HTTP police that jumps into action if there's a non-idempotent doGet method being written. But it's the developer's fault nonetheless for not knowing his stuff.
Ulf Dittmer wrote:It's the job of the developer to ensure that his/her code does not violate specifications. It's not like there's an HTTP police that jumps into action if there's a non-idempotent doGet method being written. But it's the developer's fault nonetheless for not knowing his stuff.
In Head First Servlet and JSp book they have given do-Get() method is non-idempotent and HTTP 1.1 GET method is idempotent. , how IS it ?? , than your saying what they have given is wrong ??
It's not that GET is automatically idempotent. It's that it should be. If you write an application with non-idempotent GET requests you are, as Ulf says, violating the specification. Anyone can violate a specification, it's just not a good idea.
Madangopal Venkatesan wrote:Hence, POST posts side effects while GET does not!
Not correct. I can write code in the doGet() method of a servlet that deletes the entire database.
GET's should not have side effects, but just because something is a GET doesn't mean that it will not. As already pointed out multiple times, it's the responsibility of the programmer to follow the rules.
The concept is easy, but a lot of the 'net does not implement it.
An idempotent action is one that if repeated, gets the same result, and results in the same state. There is no requirement that idempotent actions be GET, but they usually are.
In Bear's twisted example, a GET that deletes the whole database can in idempotent. The GET deletes the database, and returns a "database is gone" response/page/status. If you repeat it, it will still delete the database and return the same thing.
A more useful example happens with a "buy" button on a webstore. You want to press the "buy" button once, and get the item. Pressing it twice should *not* get you two of them. An idempotent action would have the "buy" function return "one item bought" and the state of the server has one item in the "bought/to be shipped" state. If you repeat it, it still should have only one item in the bought state.
As far I remeber in Head First, while on this discussion, they have mentioned that they were talking purely in terms of "side-effects" and not "Repeatability", which holds holds true when you talk about Idempotent in any other scenario.
In HF, what they tried explaining was while the specs say HTTP GET must be idempotent, in terms of side effects, it is whole and sole responsibility of programmer to make sure that doGet is idempotent as well. There is nothing that can stop you doing anything you want from doGet.
Regards, Suhas S. Mandrawadkar.
Certifications: SCJP 6, SCWCD 5, Oracle WebLogic Server Administrator, OCE Java EE 6 EJB Developer
Idempotency is about repeating the same action twice and getting different results. A GET request is usually used for a read, but an update or a delete would also be idempotent... because whether you read, update or delete, the result will still be the same whether you submitted the same request once or 15000 times. If you create a record in your database, you should use a POST request, because if you submit that request twice, it will add two records, which means the state of your application will not be the same anymore. Notice I said should, not have to, because you still CAN make a GET-request non-idempotent and a POST request idempotent if you so desire... It's just bad practice.
The HTTP specification specifies that POST should be the only method that is non-idempotent. So that means whenever you write a non-idempotent servlet... You should implement doPost().
Hope that explains it.
Oracle Certified Professional: Java SE 6 Programmer
Oracle Certified Expert: Java EE 6 Web Component Developer
Oracle Certified Expert: Java EE 6 Enterprise JavaBeans Developer
Author and all-around good cowpoke
Joined: Mar 22, 2000
This discussion is getting weird.
My understanding is that a GET should return the state of a resource and produce NO side effects. So - no delete of a database or any other modification of a resource on a GET.
POST, PUT and DELETE are provided to modify resources.