An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state. In other words, an idempotent method should not have any side-effects (except for keeping statistics). Implemented correctly, the
DELETE methods are idempotent, but not the
POST method. All safe methods are also idempotent.
To be idempotent, only the actual back-end state of the server is considered, the status code returned by each request may differ: the first call of a
DELETE will likely return a
200, while successive ones will likely return a
404. Another implication of
DELETE being idempotent is that developers should not implement RESTful APIs with a delete last entry functionality using the
Note that the idempotence of a method is not guaranteed by the server and some applications may incorrectly break the idempotence constraint.
GET /pageX HTTP/1.1 is idempotent. Called several times in a row, the client gets the same results:
GET /pageX HTTP/1.1 GET /pageX HTTP/1.1 GET /pageX HTTP/1.1 GET /pageX HTTP/1.1
POST /add_row HTTP/1.1 is not idempotent; if it is called several times, it adds several rows:
POST /add_row HTTP/1.1 POST /add_row HTTP/1.1 -> Adds a 2nd row POST /add_row HTTP/1.1 -> Adds a 3rd row
DELETE /idX/delete HTTP/1.1 is idempotent, even if the returned status code may change between requests:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted DELETE /idX/delete HTTP/1.1 -> Returns 404
- Definition of idempotent in the HTTP specification.