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 GET, HEAD, PUT, and DELETE são idempotentes, mas não o método POST. Todos os métodos 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 DELETE deve retornar 200, enquanto as sucessivas devem retornar 404. Outra implicação de o 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
Saber mais
Conhecimento comum
- Definição de "idempotent" na especificação de HTTP.