Articles

What is an Idempotent Operation?

introdução

neste artigo, vamos ver o que é uma operação idempotente, porque a idempotência é útil, e vamos olhar para a idempotência em repouso.o que é idempotência?

simplificando, podemos realizar uma operação idempotente várias vezes sem alterar o resultado.além disso, a operação não deve causar efeitos secundários após a primeira execução bem sucedida.

vamos olhar para dois exemplos simples.

2, 1. Valor absoluto

uma função que retorna o valor absoluto é idempotente; não importa quantas vezes aplicá-lo ao mesmo número, ele sempre retorna o mesmo resultado.

Vamos considerar a função de:

em Seguida, o seguinte é verdadeiro:

Exemplo:

Em contraste, uma função que inverte o sinal de um número não é idempotente:

Então:

Exemplo:

2.2. Atualizar o endereço

outro exemplo prático de uma operação idempotente seria atualizar os detalhes de contato de um usuário no sistema. Digamos que actualizamos apenas o número de telefone. O efeito colateral desta atualização é que nós enviamos uma mensagem de texto com um código de verificação para o novo número. Temos três cenários possíveis:

  • A primeira mensagem de atualização foi processado com sucesso, o número foi atualizado no sistema, e a mensagem de texto foi enviada. Quando a mensagem de atualização for enviada novamente, nada acontecerá. Além disso, a mensagem não é enviada pela segunda vez.
  • a primeira actualização falha. O sistema não é atualizado, e nenhuma mensagem de texto é enviada. Se a segunda atualização for bem sucedida, o sistema é atualizado, e a mensagem de texto é enviada.
  • a primeira actualização falha. Antes que outra atualização seja enviada, o Usuário é desativado no sistema. Como o estado do sistema mudou, uma segunda atualização do número de telefone não afeta.

Por Que idempotência?

Idempotence garante que a mesma solicitação leva ao mesmo estado do sistema, e nenhuma ação é executada involuntariamente mais de uma vez.

Como exemplo, vamos olhar para um pedido do remetente s para enviar dinheiro através de um serviço de pagamento PS para o receptor R.

3.1. Exemplo não-idempotente

Aqui está a versão não-idempotente do pedido:

na primeira tentativa, s envia um pedido para enviar $10 para R. PS recebe as mensagens; no entanto, a transferência real falha. PS envia uma mensagem de erro para S que não recebe essa mensagem devido a uma falha de rede.

S não sabe se a transferência foi bem sucedida, então ele tenta novamente. Desta vez a transferência para R é bem sucedida, e PS envia uma mensagem de confirmação para S. novamente, a confirmação falha, E S não sabe se a transferência foi bem sucedida ou não.portanto, ele tenta pela terceira vez. PS recebe a mensagem, considera-a como um novo pedido, envia o dinheiro para R, e retorna uma confirmação para S.

Este não é um pedido idempotente porque pretendemos repetir o mesmo pagamento e não enviá-lo duas vezes.

3, 2. A chave de idempotência

pagamentos são um bom exemplo para ilustrar a utilidade do idempotence. No exemplo anterior, vimos que o pagamento A R é executado várias vezes porque S se aposenta sem saber que a transferência já tinha sido bem sucedida.

Se a operação fosse idempotente, este não teria sido o caso. Mas como é que o PS sabe que o S acabou de recuperar o mesmo pagamento e não quer enviar um segundo pagamento de $10 para S?

para conseguir isso, S inclui uma chave de idempotência em seu pedido para PS. Esta chave pode ser, por exemplo, um UUID. Se o PS recebe um pedido com a mesma chave de idempotência, sabe que é uma repetição. Se não viu a chave antes, sabe que é um novo pedido.

Vamos olhar para o idempotente versão do exemplo anterior:

Aqui, a primeira tentativa e primeiro de repetição são as mesmas como no não-idempotente versão, exceto que o pedido inclui o idempotence chave (65TH68M5 no nosso exemplo).a diferença importante é a segunda repetição.: PS recebe a mensagem, descobre que uma mensagem com a mesma chave de idempotence já foi processada com sucesso, e retorna uma confirmação para S sem enviar o dinheiro para R novamente.

aqui, o benefício da idempotência é que S pode repetir quantas vezes quiser sem ter que se preocupar com um duplo pagamento. PS não precisa se preocupar que S recebe a confirmação, como ele sabe que S pode repetir caso ele não tenha recebido a mensagem.

A desvantagem desta abordagem é que PS precisa armazenar todas as chaves recebidas. Isto pode ser bom se não houver muitos pedidos; no entanto, se a frequência do pedido é muito alta, pode ser problemático. Uma solução pode ser expirar a chave de idempotence após algum tempo.

idempotência e repouso

4.1. Visão geral

vamos dar uma breve olhada em como a idempotência se aplica aos verbos HTTP, que são importantes para entender quando queremos construir uma API de descanso. Uma referência muito detalhada de todos os verbos HTTP pode ser encontrada no RFC 7231.

a tabela seguinte mostra quais verbos são (ou devem ser) idempotentes.

4.2. As operações de Idempotent

GET, HEAD E OPTION são claramente idempotent, pois só lêem dados, mas não criam, atualizam ou apagam quaisquer recursos.

PUT é idempotente, uma vez que atualiza um recurso ou cria um novo se não existir. Se enviarmos a mesma atualização várias vezes, o recurso não deve mudar.

4. 3. As operações não-idempotentes

POST não tem que ser idempotent pois cria um novo recurso e, se chamado novamente, normalmente cria outro recurso. No entanto, ele pode ser implementado como uma operação idempotente também.

a operação PATCH actualiza um recurso parcialmente e não tem necessariamente de ser idempotente. Vamos olhar para um exemplo para entender a diferença entre PUT e PATCH melhor:

digamos que queremos adicionar um item a um carrinho de compras em uma loja online. Se usarmos PUT, precisamos enviar os dados completos do carrinho de compras, incluindo todos os itens que já estão no carrinho. Com PATCH, podemos enviar apenas o item a ser adicionado, e ele será adicionado à lista de itens já no carrinho.

se enviarmos o pedido de PATCH novamente, o mesmo item será adicionado novamente. Claro que, quanto ao POST, podemos implementar um PATCH idempotent também.

4.4. A resposta HTTP

é importante notar que várias chamadas para uma operação idempotente não resultam necessariamente na mesma resposta HTTP.

PUT, for example, will return 201 (Created) if a resource is created, or 200 (OK) or 203 (No Content) if a resource was updated.

uma remoção, por exemplo, pode retornar 200 (OK) ou 204 (sem conteúdo) quando uma remoção real ocorre. Quaisquer chamadas posteriores retornarão 404 (não encontradas).

conclusão

neste artigo, vimos o que a idempotência significa, quais são os benefícios da idempotência, e como se relaciona com o descanso.

mesmo que o significado geral de idempotência seja fácil de entender, Pode ser bastante complicado considerar todas as subtilezas como efeitos colaterais e respostas HTTP durante o projeto de uma API.