POST is not idempotent

An HTTP GET is just for getting things, and it’s not supposed to change anything on the server. So a GET is, by definition (and according to the HTTP spec) idempotent. It can be executed more than once without any bad side effects.

POST is not idempotent—the data submitted in the body of a POST might be destined for a transaction that can’t be reversed. So you have to be careful with your doPost() functionality!

Note

GET is idempotent. POST is not.

It’s up to you to make sure that your web app logic can handle scenarios like Diane’s, where the POST comes in more than once.

image with no caption

Note

GET is always considered idempotent in HTTP 1.1...

What’s to stop me from using the parameters in GET to update the server?

...even if you see code on the exam that uses the GET parameters in a way that causes side-effects! In other words, GET is idempotent according to the HTTP spec. But there’s nothing to stop you from implementing a non-idempotent doGet() method in your servlet. The client’s GET request is supposed to be idempotent, even if what YOU do with the data causes side-effects. Always keep in mind the difference between the HTTP GET method and your servlet’s doGet() method.

Note

Note: there are several different uses of the word “idempotent”; we’re using it in the HTTP/servlet way to mean that the same request can be made twice with no negative consequences on the server. We do *not* use “idempotent” to mean that the same request always returns the same response, and we do NOT mean that a request has NO side effects.

Get Head First Servlets and JSP, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.