Здравствуйте, Pauel, Вы писали:


P>Вот у нас есть два варианта реализации операции, что выберешь?

P>Явный контроль идемпотентности
P>

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

P>Магический
P>

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

Простите, а контроль со стороны кого?
Клиента? Сервера? Программиста?

Это все работает не так как вы думаете.
Вот вы делаете АПИ, а я пытаюсь его использовать. Мы оба читали спецификации.
Я вижу метод PUT и понимаю что могу спокойно добавить код повтора запроса если получил ошибку 5xx или вообще не получил ответа из-за проблем сети. В случае с POST это в общем случае не так.

Увидев в сигнатуре метода idempotencyKey я могу сделать предположение что метод будет идемпотентным, но это будет завесить от семантики payload. Если это JSON Patch, то у меня будут закрадываться сомнения, что метод действительно идемпотентный и я могу спокойно повторять вызов с одними и теми же параметрами.

Кроме того, с точки зрения тестирования явное указание idempotencyKey скорее всего приведет к том, что при тестировании в postman будут менять payload и не будут менять idempotencyKey с абсолютно непонятными последствиями.

Поэтому я бы рекомендовал отказаться от идемпотентности POST с JSON Patch и аналогичным payload.