Um método HTTP é idempotente se uma requisição idêntica pode ser feita uma ou mais vezes em sequência com o mesmo efeito enquanto deixa o servidor no mesmo estado. Em outras palavras, um método idempotente não deveria possuir nenhum efeito colateral (exceto para manter estatísticas). Implementados corretamente, o , , , e são métodos idempotentes, mas não o método . Todos os métodos seguros também são idempotentes.
Para ser idempotente, somente o estado atual do back-end de um servidor deve ser considerado, o código de status retornado por cada requisição pode variar: a primeira chamada de um vai provavelmente retornar um , enquanto as chamadas sucessivas vão provavelmente retornar . Outra implicação do ser idempotente é de que os desenvolvedores não deveriam implementar APIs RESTful com a funcionalidade de deleção de última entrada usando o método .
Note que a idempotência de um método não é garantida pelo servidor, algumas aplicações também podem quebrar a constante de idempotência.
não é idempotente. Se ele for chamado diversas vezes, ele adicionará novas entradas.
é idempotente. Chamado diversas vezes em sequência, ele vai retornar o mesmo resultado.
Fonte: https://developer.mozilla.org/pt-BR/docs/Glossary/Idempotent
Método HTTP idempotente deixa o servidor no mesmo estado após sequência de requisição idêntica.
Idempotentes: Get, Head, Put, Delete;
Não idempotente: Post.
Isto é, após cada Post, pode ser inserido novo registro no banco de dados.
Uma preocupação de nível mais alto é que a operação pode não ser idempotente (isto é, não pode ser repetida com segurança). O caso simples é o de operações idempotentes como solicitações e respostas de DNS. O cliente pode seguramente retransmitir essas solicitações várias vezes se nenhuma resposta estiver por vir. Não importa se o servidor nunca recebeu a solicitação, ou se foi a resposta que se perdeu. A resposta, quando finalmente chega, será a mesma (supondo que o banco de dados do DNS não seja atualizado nesse ínterim). Porém, nem todas as operações são idempotentes, por exemplo, quando elas têm efeitos colaterais importantes, como incrementar um timer. A RPC para essas operações exige semântica mais robusta, de modo que, quando o programa chama um procedimento, ele não seja executado várias vezes. Nesse caso, pode ser necessário estabelecer uma conexão TCP e enviar a solicitação por ela, em vez de usar UDP.
Fonte: Redes de computadores_Tanenbaum_5ª Edição - pág 343