Como tratar a Idempotência?

Fala Fernando, tudo bem ?

Então o método post não é considerado idempotente. Veja aqui: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

SAFE – operações desse tipo são idempotentes e não alteram estado no servidor (GET, HEAD).

UNSAFE – operações desse tipo não são idempotentes e alteram estado no servidor (POST). Se repetida, o estado da informação sempre se altera.

IDEMPOTENT – operações desse tipo são idempotentes e alteram estado no servidor (PUT, DELETE).

Uma operação é considerada idempotente se o resultado dele for bem sucedida indiferente do numero de vezes que ela for executada.

No caso de operações que alteram o estado da sua informação é comum se utilizar de transações (ver JTA) para solucionar este problema. Quando algo dá errado a transação não é efetivada, voltando para o estado anterior.

Espero ter ajudado. Abraço!

Rafael, obrigado pela resposta, mas acho que você não entendeu muito bem a minha pergunta. Se você reparar vai perceber que eu afirmei que POST - NÃO é Idempotente.

A questão não é como tratar do lado do servidor (usando JTA ou qualquer outra coisa) e sim como tratar do lado do cliente. Ok?

Imagine a situação em que no aplicativo o usuário submeteu um formulário. No meio do processo caiu a conexão, o servidor recebeu esses dados e processou. No entanto, o aplicativo não teve esse feedback (se processou ou não). Qual a melhor ação a se tomar nesse caso? Fazer uma busca? Enviar para outra tela? Tentar submeter novamente?

"Como tratar a NÃO idempotencia no lado do cliente?"

Opa, me desculpa .. Realmente li errado.

Então no cliente em geral se estivermos falando de um request tradicional, síncrono, não tem muito o que fazer, se não vier um response mesmo que seja de erro, o browser só vai informar que perdeu conexão e seu usuário vai precisar refazer uma requisição quando tudo estiver normalizado. Este caso é problemático no post pois duplicaria informação, e pode ser contornado com validação server side antes de alterar o estado, em casos onde as informações sejam mais sensíveis.

Se estivermos falando de uma requisição ajax, aí é possível no codigo js prever uma lógica no cliente pra reagir em caso de perda de resposta, e informar o usuário por exemplo, planejar uma nova requisição na sequência, ou qualquer outro tratamento voltado ao negócio da app.

Abraço!