API indisponible ou données en retard : quelle réponse envoyer ?
dans Doctrine
Une dépendance ne répond plus : servir une copie, attendre ou refuser dépend de l’opération. Les réponses HTTP doivent rendre ce choix clair pour le client.
Articles
Liste des articles rédigés par les contributeurs, mis à disposition des visiteurs
HTTP et idempotence : quand peut-on réessayer une requête ?
dans Doctrine
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.
Événements : éviter les pertes et préparer la reprise
dans Méthodes
Une commande expédiée met à jour une liste et déclenche un courriel. Ces effets ne se réparent pas de la même façon : voici comment organiser leur reprise.
Timeout, retry, outbox : choisir une protection adaptée à la panne
dans Doctrine
Un service ralentit ou un message revient en double : timeout, retry, outbox et idempotence répondent à des risques différents. Voici comment les combiner.
Après une coupure : réconcilier les données et compenser les actions
dans Doctrine
Au retour du réseau, les données peuvent diverger et certains paiements être déjà faits. Comment remettre les copies à jour et traiter les effets à corriger.
Idempotence : éviter de traiter deux fois la même demande
dans Références
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.