Timeout, retry, outbox : choisir une protection adaptée à la panne
Un service ralentit ou un message revient en double : timeout, retry, outbox et idempotence répondent à des risques différents. Voici comment les combiner.
Article
HTTP et idempotence : quand peut-on réessayer une requête ?
Une réponse perdue ne signifie pas que l’opération a échoué. Méthodes HTTP, clés d’idempotence et suivi du résultat aident à réessayer sans créer de doublon.
Vous demandez la création d'un paiement, puis la connexion se coupe avant la réponse. Le paiement a-t-il été créé ? Renvoyer la demande peut être nécessaire, mais peut aussi en créer un second. L'idempotence permet de définir ce qui doit se passer lorsqu'une même intention revient plusieurs fois.
Une même demande doit conserver le même effet attendu
Une opération idempotente produit le même effet attendu sur le serveur lorsqu'elle est répétée à l'identique. Cela ne signifie pas que toutes les réponses sont identiques ni qu'aucune trace supplémentaire n'est écrite.
GET, PUT et DELETE sont définies comme idempotentes par HTTP. Les méthodes sûres, comme HEAD, le sont également. POST et PATCH ne le sont pas par définition, même si une opération particulière peut offrir cette garantie.
Le serveur doit respecter la sémantique annoncée. Employer PUT pour déclencher un nouveau débit à chaque appel ne rendrait pas l'opération idempotente.
Prendre le cas d'une ressource identifiée
Un client demande par PUT que la ressource /preferences/alice représente un état donné. Répéter le même remplacement vise le même état, à la même adresse.
Un second DELETE peut répondre que la ressource n'existe plus. La réponse diffère de la première, mais l'effet demandé reste sa suppression.
Cette propriété ne règle pas les modifications concurrentes. Un remplacement rejoué peut encore écraser une évolution faite entre-temps si le contrat ne protège pas cette situation. Les préconditions de version répondent à ce besoin distinct.
Rendre un POST rejouable avec une clé stable
Pour créer un paiement, le client peut envoyer une clé d'idempotence propre à cette intention. Le serveur conserve l'association entre cette clé, la demande et son résultat selon une politique définie.
Si le client doit réessayer, il réutilise la même clé et les mêmes paramètres. Une nouvelle clé représenterait potentiellement une nouvelle opération.
Le contrat doit préciser la durée de conservation, le périmètre de la clé, le traitement de deux appels simultanés et la réponse à une clé réutilisée avec un contenu différent. Ce dernier cas doit être signalé plutôt que masqué.
La coordination doit couvrir l'effet réellement produit. Un simple cache de réponses placée devant une écriture non protégée peut laisser une fenêtre dans laquelle deux appels exécutent le même paiement.
Lire l'erreur avant de choisir une reprise
| Situation | Conduite à prévoir |
|---|---|
| Connexion interrompue, résultat inconnu | Consulter le résultat ou reprendre avec les garanties d'idempotence prévues. |
429 ou 503 avec Retry-After | Respecter l'attente indiquée, puis réessayer si l'opération le permet. |
| Conflit ou précondition non satisfaite | Relire l'état et réexaminer la modification. |
| Demande invalide | Corriger la demande avant un nouvel essai. |
| Autre erreur serveur | Examiner le contrat et l'état de l'opération ; tous les 5xx ne justifient pas une répétition automatique. |
Un code de statut apporte une information, pas une autorisation universelle de recommencer. Sur une opération non idempotente, une erreur peut survenir après l'effet métier.
Les reprises doivent être limitées, espacées et, si nécessaire, réparties avec un léger délai aléatoire. Plusieurs couches qui réessaient chacune peuvent multiplier les appels bien au-delà du nombre prévu.
Configurer les intermédiaires selon le contrat
Une passerelle ne connaît pas toutes les garanties métier. Elle doit respecter les méthodes et les règles de reprise définies pour les routes concernées.
Une clé d'idempotence comprise uniquement par le serveur d'application ne donne pas automatiquement à un proxy le droit de rejouer n'importe quel POST. Le comportement de chaque composant doit être explicite.
Prévoir aussi la répétition d'une compensation
Annuler une réservation ou rembourser un paiement constitue une nouvelle opération. Elle peut elle aussi rencontrer une réponse perdue et être répétée.
Une compensation doit donc être conçue avec ses propres identifiants, ses limites et son suivi. Un remboursement en double aggraverait l'incident initial.
La réponse peut fournir un lien vers le résultat et les actions encore possibles. Cette description du parcours aide le client à reprendre, sans remplacer les garanties d'exécution du serveur.
Pour vérifier l'ensemble, simulez une réponse perdue après réussite, puis rejouez la même demande. Le résultat attendu est un effet métier unique et une réponse permettant au client de comprendre ce qui s'est passé.
Sources
Explorer
Sur le même sujet
Choisis dans l’index d’après les étiquettes de cet article — les plus proches d’abord, hors de sa série. Rien n’est écrit à la main : un article publié demain avec les mêmes étiquettes y prendra place.
Idempotence : éviter de traiter deux fois la même demande
Un paiement sans réponse peut avoir réussi. L’idempotence permet de réessayer sans double débit, à condition de reconnaître la demande et garder son résultat.
Faire évoluer une API utilisée par des agents sans casser leurs parcours
Un agent doit pouvoir identifier le contrat utilisé et comprendre son évolution. Versions, dépréciation, liens et erreurs explicites facilitent la migration.
Laisser un commentaire
Votre commentaire sera relu avant d'être publié.