Une méthode HTTP est idempotente si une requête identique peut être effectuée une ou plusieurs fois de suite avec le même effet tout en laissant le serveur dans le même état. En d’autres termes, une méthode idempotente ne devrait avoir aucun effet secondaire (sauf pour la tenue de statistiques). Implémentées correctement, les méthodes GETHEADPUT et DELETE sont idempotentes, mais pas les méthodes POST méthode. Toutes les méthodes sûres sont également idempotentes.

Pour être idempotent, seul l’état réel du serveur principal est pris en compte, le code d’état renvoyé par chaque requête peut différer : le premier appel d’un DELETE renverra probablement un 200, tandis que les appels successifs renverront probablement un 404. Une autre implication de DELETE étant idempotent est que les développeurs ne doivent pas implémenter d’API RESTful avec une fonctionnalité de suppression de la dernière entrée en utilisant la méthode DELETE.

Notez que l’idempotence d’une méthode n’est pas garantie par le serveur et que certaines applications peuvent casser incorrectement la contrainte d’idempotence.

GET /pageX HTTP/1.1 est idempotent. Appelé plusieurs fois de suite, le client obtient les mêmes résultats :

GET /pageX HTTP/1.1GET /pageX HTTP/1.1GET /pageX HTTP/1.1GET /pageX HTTP/1.1

POST /add_row HTTP/1.1n’est pas idempotent ; s’il est appelé plusieurs fois, il ajoute plusieurs lignes :

POST /add_row HTTP/1.1POST /add_row HTTP/1.1 -> Adds a 2nd rowPOST /add_row HTTP/1.1 -> Adds a 3rd row

DELETE /idX/delete HTTP/1.1 est idempotent, même si le code d’état renvoyé peut changer entre les requêtes :

DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX existsDELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deletedDELETE /idX/delete HTTP/1.1 -> Returns 404