een HTTP-methode is idempotent als een identiek verzoek één of meerdere keren achter elkaar kan worden gedaan met hetzelfde effect terwijl de server in dezelfde staat blijft. Met andere woorden, een idempotente methode mag geen bijwerkingen hebben (behalve voor het bijhouden van statistieken). Correct geïmplementeerd zijn deGETHEADPUT, enDELETE methoden idempotent, maar niet dePOST methode. Alle veilige methoden zijn ook idempotent.

om idempotent te zijn, wordt alleen de werkelijke back-end status van de server in aanmerking genomen, de statuscode die door elke aanvraag wordt geretourneerd, kan verschillen: de eerste aanroep van een DELETE zal waarschijnlijk een 200 retourneren, terwijl opeenvolgende waarschijnlijk een 404retourneren. Een andere implicatie dat DELETE idempotent is, is dat ontwikkelaars geen RESTful API ‘ s moeten implementeren met een delete last entry functionaliteit met behulp van de DELETE methode.

merk op dat de idempotentie van een methode niet wordt gegarandeerd door de server en dat sommige toepassingen de idempotentiebeperking ten onrechte kunnen verbreken.

GET /pageX HTTP/1.1 is idempotent. Meerdere keren in een rij, de klant krijgt dezelfde resultaten:

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

POST /add_row HTTP/1.1 is niet idempotent; als het meerdere malen, het voegt een aantal rijen:

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 idempotent, zelfs als de geretourneerde status code kan veranderen tussen vragen:

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