Choisir la bonne procédure de reprise
Le même code d’erreur décrit deux situations différentes. Vérifiezretryable avant
d’agir ; le statut HTTP seul ne permet pas de savoir s’il faut réessayer.
Données différentes
Requête toujours en cours de traitement
Cet exemple comporte également l’en-tête de réponse HTTPRetry-After: 1.
Conserver une identité de nouvelle tentative stable
Pour les opérations qui documentent l’idempotence, la clé est limitée à l’organisation, au compte de service, à la méthode HTTP, au chemin de la ressource et à la version d’API résolue. La modification de l’un de ces éléments crée une identité de nouvelle tentative différente ; elle ne permet pas de récupérer l’opération d’origine. La rotation d’un identifiant au sein du même compte de service ne modifie pas cette identité, bien que l’identifiant de remplacement doive toujours disposer des autorisations nécessaires. Conservez la clé, le corps, le chemin et la version d’origine lors d’une reprise après un délai d’attente dépassé. Ne générez pas une nouvelle clé simplement pour contourner un conflit : l’écriture d’origine a peut-être déjà abouti. Récupérez la ressource lorsque son ID est connu et appliquez la procédure de reprise documentée pour l’opération. Une relecture terminée comporteIdempotent-Replayed: true lorsque l’opération documente la relecture des réponses.
L’envoi d’un en-tête Idempotency-Key ne rend pas une opération idempotente, sauf si sa
référence prend explicitement en charge cet en-tête. La protection contre les nouvelles tentatives est limitée par la
politique de rétention de l’opération ; elle ne constitue pas une garantie permanente contre les doublons.
Si le traitement reste non résolu, contactez le Support de Living Security
en indiquant request_id, l’horodatage UTC, la méthode, le chemin et la version d’API. N’incluez jamais
de clé d’API, de secret client ni de jeton d’accès.