Um método HTTP é idempotente se, e só se, o mesmo pedido puder ser feito mais do que uma vez, tendo sempre o mesmo resultado e deixando o servidor no mesmo estado. Por outras palavras, um método idempotente não deve ter efeitos secundários. Implementados corretamente, os métodos {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}}, and {{HTTPMethod("DELETE")}} são idempotentes, mas não o método {{HTTPMethod("POST")}}. Todos os métodos {{glossary("safe")}} também são idempotentes.
Para ser idempotente, apenas o "back-end" do servidor é considerado, sendo que o estado retornado por cada pedido pode diferir: a primeira chamada de {{HTTPMethod("DELETE")}} deve retornar {{HTTPStatus("200")}}, enquanto as sucessivas devem retornar {{HTTPStatus("404")}}. Outra implicação de o {{HTTPMethod("DELETE")}} ser idempotente é que os programadores não devem implementar APIs RESTful com a funcionalidade de apagar última entrada usando o método de DELETE.
É de notar que a idempotência de um método não é garantida pelo servidor e algumas aplicações podem incorretamente violar a constrição de idempotência.
GET /pageX HTTP/1.1 é idempotente. Com várias chamadas ao servidor, o cliente obtém os mesmos resultados:
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 não é idempotente; com várias chamadas ao servidor, adiciona novas linhas:
POST /add_row HTTP/1.1 POST /add_row HTTP/1.1 -> Adiciona uma 2ª linha POST /add_row HTTP/1.1 -> Adiciona uma 3ª linha
DELETE /idX/delete HTTP/1.1 é idempotente, mesmo que o estado de retorno seja diferente entre cada chamada:
DELETE /idX/delete HTTP/1.1 -> Returns 200 se idX existir DELETE /idX/delete HTTP/1.1 -> Returns 404 visto que idX acabou de ser apagado DELETE /idX/delete HTTP/1.1 -> Returns 404