Choisir la bonne reprise
Le même code d’erreur décrit deux situations différentes. Vérifiezretryable avant
d’agir; l’état HTTP seul ne vous indique pas s’il faut effectuer une nouvelle tentative.
Données d’entrée différentes
Requête toujours en cours de traitement
Cet exemple comprend également l’en-tête de réponse HTTPRetry-After: 1.
Conserver une identité de nouvelle tentative stable
Pour les opérations dont la documentation prévoit 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 de l’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 d’accès sous le même compte de service ne modifie pas cette identité, bien que l’identifiant de remplacement doive tout de même disposer des autorisations requises. 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é dans le seul but de contourner un conflit : l’écriture d’origine a peut-être déjà réussi. Récupérez la ressource lorsque son ID est connu et utilisez la procédure de reprise documentée de l’opération. Une relecture terminée comporteIdempotent-Replayed: true lorsque l’opération documente la relecture de réponse.
L’envoi d’un 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 conservation de l’opération; elle ne constitue pas une garantie permanente contre les doublons.
Si le traitement reste non résolu, communiquez avec l’assistance de Living Security
en indiquant request_id, l’horodatage UTC, la méthode, le chemin et la version de l’API. N’incluez jamais
de clé d’API, de secret client ni de jeton d’accès.