Re[13]: Идемпотентность POST - хорошая ли практика?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.22 10:44
Оценка: 37 (2) +1
Здравствуйте, Pauel, Вы писали:
P>Хорошо, я согласен, идемпотентность не относится к бизнес-логике.
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>

Без контекста — непонятно.
Чтобы идемпотентностью пользоваться, нужен какой-то код обвязки вызовов на клиенте.
То есть, мы не просто делаем где-то в коде клиента httpClient.PostAsync(orderServiceUrl, orderUpdateContent). Нам надо
1. Записать в локальную базу инфу о том, что "worflow #xxxxxxx is going to update the order #yyyyyyy, idempotence key #kkkkk, update params $pppppppp".
2. Попытаться выполнить тот самый POST, или PUT, или PATCH
3. В зависимости от результата либо перейти по успешной ветке, либо по ветке неудачи, либо вернуться на шаг 2.

Как у нас устроен клиент? Возможно, все эти шаги — часть магии некоего фреймворка или workflow engine. Тогда мы в прикладном коде вообще идемпотентность не описываем; с его точки зрения, в сигнатуру вызова входит только прикладные части операции. А вопросы прозрачного сохранения состояния workflow в базу, восстановления после сбоев, ретраев и прочие подробности от прикладного программиста скрыты. Заодно лишая его возможности напороть в реализации.

Дальше — а как устроен сервер? Вот вы написали аннотацию метода, а дальше что?
Будете ли вы вручную выполнять сравнение пришедших в order параметров с актуальной версией, и сохранять значение ключа идемпотентности в базу?
Или, опять таки, будет работать некая магия фреймворка, которая за вас вычислит ETag, LastModified date, а заодно вытащит из запроса ключ идемпотентности и сравнит его с кодом за вас?

Первый вариант вашего кода подходит к первому случаю — весь закат солнца выполняется в ручном режиме.
Второй вариант подразумевает именно второй случай — некая магия дополнит ваш прикладной код, в котором написаны только правила обработки различных видов update для ордера.

Ну, и, опять же, операция — операцией, а есть ещё и расположение аргументов. Раз уж мы рисуем разметку, которая привязывает наш operation к глаголу HTTP, то и аргументы этой операции могут приехать из url (path или query), из тела, или из какого-то хидера. Прикладному сервера это всё равно, а вот с точки зрения клиентов и, в том числе, совместимости между разными версиями протокола это может быть важно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
u
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.