Définir le traitement des délais d’attente et l’idempotence pour éviter de créer involontairement des commandes ou opérations en double.
À qui cela s’adresse-t-il ? Les équipes de développement et les responsables de processus souhaitent intégrer de manière fiable l’écriture d’appels API.
Cas d’usage et contexte
Un délai d’attente ne précise pas avec certitude si une opération a échoué. Le serveur a peut-être déjà sauvegardé la commande, tandis que la réponse est perdue au retour. Si le même appel est répété sans vérification, des commandes, réservations ou notifications en double peuvent survenir.
Dans ce contexte, l’idempotence signifie reconnaître une requête métier répétée comme étant le même processus. Pour cela, la clé, la période de validité et la charge utile doivent correspondre. Un nouvel identifiant aléatoire à chaque répétition ne résout pas ce problème.
La démarche en détail
- Identifier les écritures critiques. Pour chaque opération, définir comment l’égalité est détectée et quels changements constituent une nouvelle requête.
- Liez un identifiant d’opération stable à une charge utile validée. Considérez des appels parallèles, des conflits et des résultats déjà sauvegardés.
- Tester les cas d’erreur : perte de réponse, serveur lent, double-clic et données modifiées sous le même identifiant. Fournir un chemin clair pour la récupération de statut ou une autorisation manuelle.
Les résultats attendus
- Définition définie d’une requête répétée
- Protection contre les actions en double non intentionnelle
- Statut compréhensible en cas de résultat incertain
- Répétitions limitées avec des cas d’erreur documentés
Préparer une décision éclairée
Ce qu’il faut, ce sont des contrats API, des charges utiles typiques et la liste des effets secondaires irréversibles. Distinguez les lectures sécurisées des actions métier d’écriture.
Les journaux doivent corréler les opérations, mais ne pas révéler de secrets ni de charges utiles sensibles complètes. La conservation des informations d’idempotence doit être associée à l’exécution des processus et à la minimisation des données.
Questions et réponses
Un client peut-il se répéter automatiquement après chaque erreur ?
Non. La répétabilité dépend du point d’arrivée et de l’erreur. Sans une idempotence convenue, une répétition peut créer un second business case.
Qu’est-ce qu’on attend avec la même clé et les données différentes ?
Un conflit clair a généralement plus de sens qu’une réécriture silencieuse. Le traitement exact appartient au contrat d’interface.