Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Логичность и понятность API.

Это всего лишь структура пейлоада. Если мы привязаны к хттп, то можно и хидер заюзать, теоретически. На самом деле если абстрагироваться от хттп, то у нас много вариантов

@Post('/orders')
newOrder(order: Delta<Order>, idempotencyKey: string): Promise<Order>

В данном случае мы явно явно требуем идемпотентность, и это будет работать вне зависимости от транспорта.

@Post('/orders')
@Idempotent()
newOrder(order: Delta<Order>): Promise<Order>

Соответсвенно на стороне бакенда всё это отражается 1 в 1, только второй вариант хуже с т.з. разработки, т.к. важный степ уходит неизвестно куда.

P>> Все равно нам нужно по этому x-request-id понять, что делать с повторным запросом. И это уже не транспорт, а бизнес-логика.

НС>Неа. Бизнес-логика, это если ключ присутствует на бизнес-уровне. А вот если ключ специальный и ей ортогонален, то не нужно тащить его в бизнес-слой.

А где и как ты собираешься проверять, повторный ли это реквест и в каком он состоянии?

Идемпотентность это свойство прежде всего бизнес-операции. Соответсвенно реализация этого свойства требует в т.ч. и поддержки транспортом. Но первично именно свойство бизнес-операции.