HTTP-menetelmä on idempotentti, jos sama pyyntö voidaan tehdä kerran tai useita kertoja peräkkäin samalla vaikutuksella jättäen palvelin samaan tilaan. Toisin sanoen, idempotent menetelmä ei pitäisi olla mitään sivuvaikutuksia (paitsi pitää tilastoja). Oikein toteutettuna GETHEADPUT ja DELETE menetelmät ovat idempotentteja, mutta eivät POST metodi. Kaikki turvalliset menetelmät ovat myös idempotentteja.

idempotentiksi katsotaan vain palvelimen todellinen taustatila, jokaisen pyynnön palauttama tilakoodi voi vaihdella: DELETE ensimmäinen puhelu palauttaa todennäköisesti 200, kun taas perättäiset todennäköisesti palauttavat 404. Toinen seuraus siitä, että DELETE on idempotentti, on se, että kehittäjien ei tulisi ottaa käyttöön levollisia sovellusliittymiä, joissa on delete last entry-toiminto käyttäen DELETE – menetelmää.

huomaa, että palvelin ei takaa menetelmän idempotenssirajoitusta ja jotkut sovellukset saattavat rikkoa idempotenssirajoituksen väärin.

GET /pageX HTTP/1.1 on idempotentti. Useita kertoja peräkkäin kutsuttu asiakas saa samat tulokset:

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

POST /add_row HTTP/1.1 ei ole idempotentti; jos sitä kutsutaan useita kertoja, se lisää useita rivejä:

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 on idempotentti, vaikka palautettu tilakoodi voi muuttua pyyntöjen välillä:

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