Idempotent

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 (en-US), HEAD (en-US), PUT (en-US), and DELETE (en-US) são idempotentes, mas não o método POST (en-US). 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 (en-US) deve retornar 200 (en-US), enquanto as sucessivas devem retornar 404 (en-US). Outra implicação de o DELETE (en-US) 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.

Conhecimento técnico