Pourquoi l'idempotence compte
Les retries arrivent toujours : timeouts, reseau instable, proxies. Sans idempotence, un retry peut doubler une action critique.
L'idempotence garantit qu'une requete repetee produit le meme effet. C'est un filet de securite.
Semantique des verbes HTTP
GET est idempotent car il ne modifie pas l'etat. PUT et DELETE sont definis comme idempotents.
POST n'est pas idempotent par defaut. Si vous voulez des retries sur POST, il faut le concevoir.
Cles d'idempotence
Une cle d'idempotence est un token unique envoye avec la requete. Le serveur memorise la premiere reponse.
Ainsi, un retry renvoie la meme reponse sans recreer l'effet.
Regles de retry sur
Les clients doivent retry seulement si l'action est sure. Sinon, utilisez des cles d'idempotence.
Les serveurs doivent renvoyer des erreurs claires pour guider la decision de retry.
Ambiguite des timeouts
Un timeout laisse le client dans le doute. L'idempotence supprime cette ambiguite.
Sinon, un endpoint de statut peut aider a verifier l'etat d'une operation.
Stockage et expiration
Les cles doivent etre stockees puis expirees. Il faut un compromis entre securite et cout.
Expirer trop vite peut recreer des doublons. Trop tard augmente le stockage.
Concurrence et race conditions
Deux requetes identiques peuvent arriver en parallele. Il faut garantir qu'une seule action est appliquee.
Utilisez des verrous, des transactions ou des contraintes uniques.
