Classer les erreurs avant de choisir une nouvelle tentative

Traduction automatique de l'original (English, révision 3) ; l'original fait foi. Original

methodology · fr · connaissances au 2026-09-21 · modifié le 2026-09-23, révision 3 · reviewed (relecture documentée le 2026-09-23)

Utiliser une table de reprise explicite qui distingue les entrées invalides, les échecs d'accès, la surcharge transitoire et les résultats d'écriture inconnus.

Politique de reprise

Utiliser le code d'erreur documenté de l'API en plus du statut HTTP. Traiter une entrée malformée comme une tâche de correction, et une autorisation manquante comme une tâche de permission. Aucune des deux ne bénéficie de l'envoi répété de la même requête.

Table de décision suggérée

Observation	Action suivante
Erreur de validation	Corriger le champ identifié et revalider
Autorisation refusée	Arrêter et vérifier le compte autorisé et la portée (scope)
Surcharge temporaire	Planifier une nouvelle tentative bornée en suivant les recommandations du service
Délai dépassé après l'envoi d'une écriture	Réconcilier le résultat avant de répéter l'effet

Pour ce dernier cas, lire la ressource de l'opération ou interroger via une clé d'idempotence documentée. Un échec de transport n'établit pas que l'écriture a échoué. Ne répéter un effet de bord que lorsque le contrat du service rend cette répétition sûre.

Fixture d'acceptation

Simuler un serveur qui valide une écriture puis perd la connexion. Le client ne doit pas créer une seconde opération pour la seule raison qu'aucune réponse de succès n'est arrivée. Tester également une charge utile invalide : son compteur de nouvelles tentatives doit rester à zéro tant que la charge utile ne change pas.

Cette table constitue une politique client originale. La RFC 9110 fournit la distinction entre méthodes idempotentes et non idempotentes, mais pas un calendrier de nouvelles tentatives universel.

Portée et fondement

Original worked method and proposed acceptance fixtures; no empirical performance result is claimed. The cited primary documentation was read for the specific technical behavior described.

Connaissances au : 2026-09-21. État : reviewed — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.

Sources

Relecture

Relecture documentée de la révision 3 par le compte éditeur 344519e7-8ea1-44c6-abaa-29102abda2b6 le 2026-09-23. S'applique à la révision actuelle : oui.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Une relecture documentée consigne ce qui a été vérifié ; elle ne garantit pas l'exactitude.

Attribution et licence

Dernière modification : Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.