advanced

REST idempotency

Обрабатывайте retries безопасно через idempotent methods, idempotency keys, conflict detection, request fingerprints и stored outcomes.

Сети делают retry. Идемпотентные операции позволяют безопасно повторять запросы без дублирования side effects.

Семантика methods:

GET, PUT, DELETE идемпотентны по определению HTTP.
POST — нет; используйте **idempotency keys** для payments, orders и записей с ненадёжными клиентами.

					POST /payments
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
Content-Type: application/json

{"amount": 1999, "currency": "USD", "orderId": "ord_123"}

Поведение сервера:

Первый запрос с key: обработать и сохранить `{ key, status, response, fingerprint }`.
Retry с тем же key и телом: вернуть сохранённый ответ (часто 200/201 с исходным телом).
Тот же key + другое тело: 409 Conflict.

Fingerprint может хешировать method, path, body и auth subject. TTL ключей — достаточно для окна retry клиента (часто 24–72ч).

На интервью: почему POST нужны keys, а PUT может обойтись без них; связь keys с unique constraints в БД; гонки и транзакции.

Типовые ошибки: keys только в памяти (теряются при рестарте), нет conflict при другом теле, idempotency без scope аутентификации, PATCH как идемпотентный без проектирования.

Компромисс: стоимость хранения idempotency records против риска дублей в деньгах/операциях — для money movement всегда оправдано.

Чеклист:

Idempotency-Key на неидемпотентные POST writes.
Persist outcomes с TTL.
409 при повторном key с другим payload.
Scope keys на tenant или user.