idempotency_key_reuse


Код	`idempotency_key_reuse`
Статус HTTP	`409 Conflict`
Можливість повтору	Перегляньте `retryable` у відповіді

Виберіть правильний спосіб відновлення

Той самий код помилки описує дві різні ситуації. Перш ніж діяти, перевірте retryable; лише за статусом HTTP неможливо визначити, чи потрібно повторювати запит.

Відповідь	Значення	Наступний крок
`retryable: false`	Ключ уже ідентифікує запит з іншими вхідними даними.	Порівняйте тіло запиту з початковим запитом. Використовуйте новий ключ лише для свідомо іншої операції.
`retryable: true`	Інший запит з цим ключем усе ще обробляється.	Залиште той самий ключ і той самий запит. Зачекайте щонайменше `Retry-After` с, після чого повторіть запит у межах обмеженого часового бюджету.

Інші вхідні дані

{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "title": "Conflict",
  "status": 409,
  "detail": "Idempotency-Key was already used with a different request.",
  "code": "idempotency_key_reuse",
  "request_id": "req_0199a1e0-7c00-7000-8000-000000000001",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "retryable": false,
  "param": "Idempotency-Key"
}

Запит ще обробляється

Цей приклад також містить заголовок HTTP-відповіді Retry-After: 1.

{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "title": "Conflict",
  "status": 409,
  "detail": "A concurrent request is still processing this Idempotency-Key. Retry shortly.",
  "code": "idempotency_key_reuse",
  "request_id": "req_0199a1e0-7c00-7000-8000-000000000001",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "retryable": true,
  "param": "Idempotency-Key"
}

Зберігайте незмінною ідентичність повторного запиту

Для операцій, у документації яких описано ідемпотентність, ключ прив’язаний до організації, службового облікового запису, методу HTTP, шляху ресурсу та визначеної версії API. Зміна будь-якого з цих елементів створює іншу ідентичність повторного запиту й не відновлює початкову операцію. Ротація облікових даних в межах того самого службового облікового запису не змінює цю ідентичність, проте нові облікові дані все одно повинні мати відповідний дозвіл. Під час відновлення після тайм-ауту зберігайте початковий ключ, тіло запиту, шлях і версію. Не створюйте новий ключ лише для того, щоб обійти конфлікт: початкова операція запису могла вже успішно завершитися. Якщо ідентифікатор ресурсу відомий, отримайте цей ресурс і скористайтеся задокументованою процедурою відновлення для цієї операції. Завершена повторна відповідь містить Idempotent-Replayed: true, якщо операція документує повторне відтворення відповіді. Надсилання Idempotency-Key не робить операцію ідемпотентною, якщо в її довідці явно не вказано підтримку цього заголовка. Захист від повторів обмежений політикою зберігання для відповідної операції; він не є постійною гарантією від дублювання. Якщо проблему з обробкою не вдається вирішити, зверніться до служби підтримки Living Security і вкажіть request_id, часову мітку в UTC, метод, шлях і версію API. Ніколи не додавайте ключ API, секрет клієнта чи маркер доступу.

Центр розробників

Публічний API v1

Довідник з API v1

Виберіть правильний спосіб відновлення

Інші вхідні дані

Запит ще обробляється

Зберігайте незмінною ідентичність повторного запиту

Центр розробників

Публічний API v1

Довідник з API v1

​Виберіть правильний спосіб відновлення

​Інші вхідні дані

​Запит ще обробляється

​Зберігайте незмінною ідентичність повторного запиту

Виберіть правильний спосіб відновлення

Інші вхідні дані

Запит ще обробляється

Зберігайте незмінною ідентичність повторного запиту