См. статью от великого Яндекса: https://habr.com/ru/company/yandex/blog/442762/

Понятно что под стажером описан опыт целой команды (никто бы не доверил стажеру проектировать архитектуру), но чтобы набить себе цену и победить в эволюционной борьбе, чтобы никто не посмел потом сказать какие же вы идиоты — придумали концепцию стажера. Ну да ладно, отвлеклись. Суть вот в чем:

Вот решение "стажера" по идемпотентности:

POST /v1/orders

{
  "from": "Москва, ул. Садовническая набережная 82с2",
  "to": "Аэропорт Внуково",
  "idempotency_key": "786706b8-ed80-443a-80f6-ea1fa8cc1b51"
}

Т.е. этот "стажер" (как позже признались в комментах — это опыт выведен из нескольких проектов) — сделал запрос POST идемпотентным. Но как мы знаем — POST не идемпотентен, т.к. еще не знает ключа ресурса — ключ только генерится.

Не логичнее ли вместо idempotency_key использовать ID и сделать этот ID типа UUID v4? Ведь по сути именно это хотел изобразить стажер:

PUT /v1/orders/786706b8-ed80-443a-80f6-ea1fa8cc1b51

{
  "id": "786706b8-ed80-443a-80f6-ea1fa8cc1b51",
  "from": "Москва, ул. Садовническая набережная 82с2",
  "to": "Аэропорт Внуково"
}

Какие минусы в этом?

Минус очевидный — это диктует тип ключей — только UUID. А если хочется чтобы ключи генерила СУБД и там спец. система для распределенной генерации ключей? Т.е. такой PUT как бы обязывает применять новую схему создания ключей.

И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.

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

S>Т.е. этот "стажер" (как позже признались в комментах — это опыт выведен из нескольких проектов) — сделал запрос POST идемпотентным. Но как мы знаем — POST не идемпотентен, т.к. еще не знает ключа ресурса — ключ только генерится.

POST не обязан быть идемпотентным, но никто не мешает сделать его идемпотентным.

S>Не логичнее ли вместо idempotency_key использовать ID и сделать этот ID типа UUID v4? Ведь по сути именно это хотел изобразить стажер:


S>

S>PUT /v1/orders/786706b8-ed80-443a-80f6-ea1fa8cc1b51

S>{
S>  "id": "786706b8-ed80-443a-80f6-ea1fa8cc1b51",
S>  "from": "Москва, ул. Садовническая набережная 82с2",
S>  "to": "Аэропорт Внуково"
S>}
S>

S>Какие минусы в этом?

Я бы так и сделал.

S>Минус очевидный — это диктует тип ключей — только UUID. А если хочется чтобы ключи генерила СУБД и там спец. система для распределенной генерации ключей? Т.е. такой PUT как бы обязывает применять новую схему создания ключей.

Ну вот я недавно думал над этим и решил, что ключи должны быть только UUID. Минусов у UUID почти нет, а плюсов много.

S>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.

Ну в идеале — согласен. На практике не всегда получается это выполнять. Ограничения архитектуры или старого кода могут играть роль. К примеру в браузере нельзя послать PUT на другой домен без разрешений CORS, а POST с определёнными ограничениям — можно. Ну это просто пример.

Кажется у вас небольшая каша в голове по этому вопросу. Вы ж совсем недавно задавали подобный вопрос про идемпотентность и защиту от дублирования http://rsdn.org/forum/dotnet/8348759.1

Автор: Shmj
Дата: 31.08.22

.

ID и idempotency_key — это совершенно разные вещи, и служат для разных целей. idempotency_key позволяет исключить повторное создание нового айтема с новым ID, а ID айтема служит для идентификации айтема при работе с ним.



PS лучше было бы такие темы писать в другой раздел. Тут ничего нет имеющего непосредственно отношение к точке нету.

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

DP>ID и idempotency_key — это совершенно разные вещи, и служат для разных целей. idempotency_key позволяет исключить повторное создание нового айтема с новым ID, а ID айтема служит для идентификации айтема при работе с ним.

Однако же если в качестве ID применить UUID и генерить на клиенте — то проблема решается сама собой. Вот чел. так и делает: https://rsdn.org/forum/dotnet/8364034.1

Автор: vsb
Дата: 20.09.22

DP>PS лучше было бы такие темы писать в другой раздел. Тут ничего нет имеющего непосредственно отношение к точке нету.

По сути все сидят на этом форуме — 90% людей.

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

S>Вот решение "стажера" по идемпотентности:

Не ту проблему решали: если нужно, чтобы в базе не было одинаковых заказов, достаточно на стороне сервера обеспечить, чтобы в базе не было одинаковых заказов.

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

S>>Вот решение "стажера" по идемпотентности:

scf>Не ту проблему решали: если нужно, чтобы в базе не было одинаковых заказов, достаточно на стороне сервера обеспечить, чтобы в базе не было одинаковых заказов.

Прочитайте статью. Как раз в том и фишка — одинаковые заказы могут быть. Как так? А вот так — приехала компания из 7 чел., в 1 машину влазит 4 чел. Сделали сначала 1 заказ а потом сразу другой — так корректно. Главное отличать когда это по воле клиента а когда по сетевой ошибке.

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

S>Прочитайте статью. Как раз в том и фишка — одинаковые заказы могут быть. Как так? А вот так — приехала компания из 7 чел., в 1 машину влазит 4 чел. Сделали сначала 1 заказ а потом сразу другой — так корректно. Главное отличать когда это по воле клиента а когда по сетевой ошибке.

Я прочитал в самом начале статьи следующее:

Когда надо было сделать API для отдачи активных заказов, Вася задумался: а может ли понадобиться заказывать одновременно несколько машин такси? Менеджеры ответили, что нет, такая возможность не нужна.

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

S>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.

Допустим, у нас есть запрос PUT/PATCH для изменения пароля пользователя.
В системе настроено правило: при неправильно введённом текущем пароле 3 раза — учётка блокируется.
У клиента очень плохой интернет, он решает поменять пароль.
В итоге запрос даже не задваивается, а улетает 4 копии.
Первая отрабатывает и меняет пароль. Остальные приходят с уже неправильным старым паролем.
Итого система видит, что какой-то негодяй пытается подобрать пароль и блокирует учётку.
Этот запрос не POST, но является ли он идемпотентным?

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

K>Я прочитал в самом начале статьи следующее:
K>

K>Когда надо было сделать API для отдачи активных заказов, Вася задумался: а может ли понадобиться заказывать одновременно несколько машин такси? Менеджеры ответили, что нет, такая возможность не нужна.

K>

Так читайте дальше:

Вася удивлен: как же так, я же спрашивал, и вы говорили мне, что это не понадобится?!

Мы не боги — никто из нас не обладает полнотой картины реальности, хотя часто думаем что обладаем и что-то там можем прогнозировать. Просто принять как факт — никто не знает что понадобится а что нет — делать максимально гибко.

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

S>Так читайте дальше:

Действительно. Пропустил, когда эту занимательную выдуманную историю по диагонали пробегал.

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

S>>Так читайте дальше:
K>Действительно. Пропустил, когда эту занимательную выдуманную историю по диагонали пробегал.

Оно можно сказать — аналитики плохие, не предугадали, не виноватая я и т.д. Но суть то не в том кто виноват — важно сделать максимально гибко. И хорошие принципы это позволяют.

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

S>Оно можно сказать — аналитики плохие, не предугадали, не виноватая я и т.д. Но суть то не в том кто виноват — важно сделать максимально гибко. И хорошие принципы это позволяют.

Сделали гибко, в итоге теперь у обычных клиентов не проходят лишние случайные заказы. Они счастливы.
Зато мамкин кулхацкер посмотрел на отправляемые запросы, сгенерировал своих дубликатов с уникальными UUID и заказал на адрес тысячу машин за наличку.
Яндекс будет рад такой ситуации или не нужно клиенту таки слепо доверять и на сервере как-то нужно следить за входными данными?

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

K>Допустим, у нас есть запрос PUT/PATCH для изменения пароля пользователя.
K>В системе настроено правило: при неправильно введённом текущем пароле 3 раза — учётка блокируется.
K>У клиента очень плохой интернет, он решает поменять пароль.
K>В итоге запрос даже не задваивается, а улетает 4 копии.
K>Первая отрабатывает и меняет пароль. Остальные приходят с уже неправильным старым паролем.
K>Итого система видит, что какой-то негодяй пытается подобрать пароль и блокирует учётку.
K>Этот запрос не POST, но является ли он идемпотентным?

В данном случае, его вполне можно сделать идемпотентным добавлением ключа идемпотентности и данный сценарий от этого только улучшится:

1. первый запрос сменит пароль, сохранит результат (ок или ошибка) в специальную таблицу с этим полученным ключом (это может быть постоянная таблица типа истории изменений пароля или временная с периодической очисткой — только для обеспечения идемпотености запросов)
2. каждый следующий запрос посмотрит наличие ключа в этой таблице и сразу вернет "ок" (ну или ошибка, если все же первый запрос был уже неудачный), даже не пытаясь собственно менять пароль.
3. Поскольку попытки смены пароля для этих последующих запросов реально не проводилось, то и учетку не блокируем.

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

F>В данном случае, его вполне можно сделать идемпотентным добавлением ключа идемпотентности и данный сценарий от этого только улучшится:

И в итоге чуть ли не каждый запрос на редактирование нужно делать идемпотентным, чтобы у пользователя не возникало фантомных ошибок и запрос действительно одно и то же возвращал.
Почему-то во многих статьях пишут именно про POST, подразумевая то, что вот этот запрос создаст новую запись и с ним очень легко захламить сервер мусором.
Плевать, что повторный PUT или DELETE скорее всего вернёт уже не статус 200, а какую-нибудь ошибку.
Я вот как-то разницу между запросами не особо вижу в плане "идемпотентности".
GET разве что особняком стоит, т.к. он на чтение работает, а у остальных примерно одинаковые проблемы.

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

K>Сделали гибко, в итоге теперь у обычных клиентов не проходят лишние случайные заказы. Они счастливы.
K>Зато мамкин кулхацкер посмотрел на отправляемые запросы, сгенерировал своих дубликатов с уникальными UUID и заказал на адрес тысячу машин за наличку.
K>Яндекс будет рад такой ситуации или не нужно клиенту таки слепо доверять и на сервере как-то нужно следить за входными данными?

Это уже другой вопрос — вопрос безопасности. Даже если ты установишь лимит — 1 клиент 1 заказ — это не спасет от подобной ситуации, т.к. мамкин кулхацкер с легкостью создаст несколько учеток даже с разных IP-адресов и точно так вызовет 1000 машин, можно даже на разные адреса.

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

K>Допустим, у нас есть запрос PUT/PATCH для изменения пароля пользователя.
K>В системе настроено правило: при неправильно введённом текущем пароле 3 раза — учётка блокируется.
K>У клиента очень плохой интернет, он решает поменять пароль.
K>В итоге запрос даже не задваивается, а улетает 4 копии.
K>Первая отрабатывает и меняет пароль. Остальные приходят с уже неправильным старым паролем.
K>Итого система видит, что какой-то негодяй пытается подобрать пароль и блокирует учётку.
K>Этот запрос не POST, но является ли он идемпотентным?

Выше вам хорошо ответили. Без ключа идемпотентности — да, запись была бы заблокирована. С ключом идемпотентности, а он один и тот же для всех 4 запросов — первый раз отработали, на все остальные сказали что все ОК.

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

S>Но как мы знаем — POST не идемпотентен

Не совсем так. У него нет требования быть идемпотентным. Но обратного требования тоже нет.
Но с точки зрения понятности API, конечно, неидемпотентный метод лучше сделать PUT.
Еще один не самый лучший момент — явное вытаскивание этого idempotency_key в бизнес-слой. Разумнее было бы передавать в каком нибудь хидере типа X-Request-ID, так как это не бизнес-сущность, а специфика транспорта.

S>Не логичнее ли вместо idempotency_key использовать ID и сделать этот ID типа UUID v4?

Логичнее.

S>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным

А если нельзя?

S> (а это можно и нужно всегда — интернет по определению не надежен)

Иногда важнее получить fail сразу же и ретраи не делать.

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

K>Почему-то во многих статьях пишут именно про POST, подразумевая то, что вот этот запрос создаст новую запись и с ним очень легко захламить сервер мусором.
K>Плевать, что повторный PUT или DELETE скорее всего вернёт уже не статус 200, а какую-нибудь ошибку.

DELETE должен вернуть 200, даже если запись была удалена ранеее. Именно по этому считаем идемпотентным.

Аналогично PUT — он полностью заменяет запись и будет всегда возвращать одно и тоже, не зависимо от очередности вызовов.

Только PATCH еще может быть не идемпотентным.

K>Я вот как-то разницу между запросами не особо вижу в плане "идемпотентности".

Вот табличка, уже приводил:

	Скрытый текст

K>GET разве что особняком стоит, т.к. он на чтение работает, а у остальных примерно одинаковые проблемы.

Не только, см. табличку.

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

DP>>PS лучше было бы такие темы писать в другой раздел. Тут ничего нет имеющего непосредственно отношение к точке нету.
S>По сути все сидят на этом форуме — 90% людей.

Это неприемлемая мотивация. Не надо постить в неподходящий форум потому что тут больше людей.

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

НС>Не совсем так. У него нет требования быть идемпотентным. Но обратного требования тоже нет.
НС>Но с точки зрения понятности API, конечно, неидемпотентный метод лучше сделать PUT.
НС>Еще один не самый лучший момент — явное вытаскивание этого idempotency_key в бизнес-слой. Разумнее было бы передавать в каком нибудь хидере типа X-Request-ID, так как это не бизнес-сущность, а специфика транспорта.

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

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

НС>>Еще один не самый лучший момент — явное вытаскивание этого idempotency_key в бизнес-слой. Разумнее было бы передавать в каком нибудь хидере типа X-Request-ID, так как это не бизнес-сущность, а специфика транспорта.

P>А что это принципиально меняет?

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

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

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

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

S>>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным
НС>А если нельзя?

На пример в каком случае?

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

S>Аналогично PUT — он полностью заменяет запись и будет всегда возвращать одно и тоже, не зависимо от очередности вызовов.
Это не так, см. спецификацию. Может вернуть 201, 200/204.

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

S>Выше вам хорошо ответили. Без ключа идемпотентности — да, запись была бы заблокирована. С ключом идемпотентности, а он один и тот же для всех 4 запросов — первый раз отработали, на все остальные сказали что все ОК.

т.е. хоть и не POST, но нужно что-то отдельно мудрить для идемпотентности?
В итоге только POST не идемпотентный или таки название метода ничего не значит?

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

S>Это уже другой вопрос — вопрос безопасности. Даже если ты установишь лимит — 1 клиент 1 заказ — это не спасет от подобной ситуации, т.к. мамкин кулхацкер с легкостью создаст несколько учеток даже с разных IP-адресов и точно так вызовет 1000 машин, можно даже на разные адреса.

и поэтому нужно сначала безоговорочно доверять тому, что прислал клиент, чтобы потом отдельно безопасностью заниматься и накручивать дополнительные проверки?

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

НС>>А если нельзя?
S>На пример в каком случае?

Например, если ты делаешь health check.

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

S>DELETE должен вернуть 200, даже если запись была удалена ранеее. Именно по этому считаем идемпотентным.

Кому он должен?
Вообще-то мне может требоваться, чтобы DELETE именно сообщал была ли запись удалена мною или её изначально не было.

S>Аналогично PUT — он полностью заменяет запись и будет всегда возвращать одно и тоже, не зависимо от очередности вызовов.

А если на сервере кто-то подписан на изменения записей и запускает какую-то операцию?
Ну, может изменения в профиле организации в итоге должен живой модератор проверить и сравнить их со сканами документов.
Заставим человека одни и те же данные дважды проверять и плевать, лишь бы на клиент одинаково код 200 улетел?

S>Вот табличка, уже приводил:

Ага. Табличка по которой все методы отличные, только чтобы у пользователя учётка не заблокировалась из-за плохого интернета, в замечательные индеподентный запрос нужно так же отдельно мудрить ключи.

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

K>т.е. хоть и не POST, но нужно что-то отдельно мудрить для идемпотентности?
K>В итоге только POST не идемпотентный или таки название метода ничего не значит?

См. табличку:

	Скрытый текст

PATCH — не идемпотентен. Т.е. ключ добавлять обязательно, если она нужна.

А PUT — не подходит для обновления пароля — он обновляет целиком всю запись и должен обеспечивать идемпотентность. Это возможно только для сущностей без состояния.

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

НС>Логичность и понятность 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 понять, что делать с повторным запросом. И это уже не транспорт, а бизнес-логика.

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

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

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

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

K>Кому он должен?
K>Вообще-то мне может требоваться, чтобы DELETE именно сообщал была ли запись удалена мною или её изначально не было.

См. табличку:

	Скрытый текст

Таковы правила. Вам либо принять либо город городить.

S>>Аналогично PUT — он полностью заменяет запись и будет всегда возвращать одно и тоже, не зависимо от очередности вызовов.

K>А если на сервере кто-то подписан на изменения записей и запускает какую-то операцию?
K>Ну, может изменения в профиле организации в итоге должен живой модератор проверить и сравнить их со сканами документов.
K>Заставим человека одни и те же данные дважды проверять и плевать, лишь бы на клиент одинаково код 200 улетел?

Тогда нельзя использовать PUT — только PATCH.

K>Ага. Табличка по которой все методы отличные, только чтобы у пользователя учётка не заблокировалась из-за плохого интернета, в замечательные индеподентный запрос нужно так же отдельно мудрить ключи.

Разберитесь.

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

S>DELETE должен вернуть 200, даже если запись была удалена ранеее. Именно по этому считаем идемпотентным.

А разве идемпотентность требует возвращать один и тот же код ответа? Мне это не очевидно.

Почему бы первому DELETE не возвращать 200, а последующим 404? Вроде это ничему не противоречит. А то, что код возврата разный, ну и что.

Да и как вообще реализовать DELETE, который будет возвращать 200 на удалённый ресурс? Это из базы нельзя ничего удалять?

В общем тут важно не переходить грань, где транспорт начнёт диктовать бизнес-логике что-то, я считаю.

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

S>>DELETE должен вернуть 200, даже если запись была удалена ранеее. Именно по этому считаем идемпотентным.

vsb>А разве идемпотентность требует возвращать один и тот же код ответа? Мне это не очевидно.
vsb>Почему бы первому DELETE не возвращать 200, а последующим 404? Вроде это ничему не противоречит. А то, что код возврата разный, ну и что.

Сорри, все-таки верно — второй DELETE вернет ошибку, однако же не поменяет состояние объекта.

Clearly, the response is different from the first request, but there is no change of state for any resource on the server-side because the original resource is already deleted.

тут

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

НС>>Еще один не самый лучший момент — явное вытаскивание этого idempotency_key в бизнес-слой. Разумнее было бы передавать в каком нибудь хидере типа X-Request-ID, так как это не бизнес-сущность, а специфика транспорта.
P>А что это принципиально меняет? Все равно нам нужно по этому x-request-id понять, что делать с повторным запросом. И это уже не транспорт, а бизнес-логика.

Можно сделать общее правило, что если передан такой ключ, то прежде чем отдавать данные на обработку в бизнес-логику проверить наличие уже отправленного ранее ответа на этот ключ и отослать его, если он был (для REST с учетом глагола можно сделать чуть разную логику для post/put/delete если есть желание).
Это можно сделать каким-то промежуточным слоем, который будет отрабатывать для всех запросов вообще и одинаково. Но значение ключа при этом тогда гораздо удобнее держать не частью бизнес-данных запроса, а чем-то техническим — хидер для rest, или поле в конверте, например, если у нас какой-то свой протокол.

При появлении нового запроса в АПИ достаточно будет прописать тот же хидер и вся магия для него заработает сразу, без каких-то правок. А если уж вдруг для каких-то запросов "стандартный" механизм не подходит, то убрать этот общий хидер и делать отдельно на урвоне бизнес-логики.

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

НС>Еще один не самый лучший момент — явное вытаскивание этого idempotency_key в бизнес-слой. Разумнее было бы передавать в каком нибудь хидере типа X-Request-ID, так как это не бизнес-сущность, а специфика транспорта.

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

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

P>На самом деле если абстрагироваться от хттп

Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.

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

В мидлвере.

P>Идемпотентность это свойство прежде всего бизнес-операции.

Однако обеспечение этой идемпотентности при помощи отдельного ключа — штука весьма универсальная, и не нужно ее копипастить в бизнес-коде по всем идемпотентным методам.

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

K>Вообще-то мне может требоваться, чтобы DELETE именно сообщал была ли запись удалена мною или её изначально не было.

В общем случае это невозможно. У тебя может запрос на удаление успешно дойти, а вот отклик сервера потеряться. При таком раскладе, если DELETE будет возвращать при удалении уже удаленного 404, ты никогда не получишь на клиенте для этого ресурса 200.
Поэтому строить клиентскую логику на основании того, что вернул DELETE — отличный способ подложить себе грабли.

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

S>А PUT — не подходит для обновления пароля — он обновляет целиком всю запись

Так сделай пароль отдельным ресурсом и обновляй его целиком.
В более хитрых ситуациях может понадобится хранить несколько паролей, да еще и со связанной с ними информацией типа даты создания. Это уже точно отдельный ресурс.

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

НС>Здравствуйте, Shmj, Вы писали:

S>>А PUT — не подходит для обновления пароля — он обновляет целиком всю запись

НС>Так сделай пароль отдельным ресурсом и обновляй его целиком.
НС>В более хитрых ситуациях может понадобится хранить несколько паролей, да еще и со связанной с ними информацией типа даты создания. Это уже точно отдельный ресурс.

Там же нужно передать и старый пароль.

1 запрос — пароль1, пароль2. Ок, поменяли.
2 такой же запрос — пароль1, пароль2 — уже не пройдет, т.к. новый пароль — это пароль2 (был установлен на предыдущем шаге).

По этому только PATCH.

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

НС>В общем случае это невозможно. У тебя может запрос на удаление успешно дойти, а вот отклик сервера потеряться. При таком раскладе, если DELETE будет возвращать при удалении уже удаленного 404, ты никогда не получишь на клиенте для этого ресурса 200.
НС>Поэтому строить клиентскую логику на основании того, что вернул DELETE — отличный способ подложить себе грабли.

Так если я не получу ответ от сервера, то клиент повторно ему запрос на удаление отправит, когда связь восстановится (либо вообще это в рамках TCP разрулится и разработчика не волнует).
Дальше и появляется вопрос:
либо сервер увидит, что это повтор уже обработанного запроса и ответит то же самое, что отвечал уже и оно потерялось
либо серверу плевать, он обработает ещё раз удаление и уже не 200, а 404 отправит.
Кроме удаления по ИД, может быть и удаление по какому-нибудь условию.
И будет странно, если "потерянный" запрос сначала удалит 10 записей в БД, а потом я пользователю покажу, якобы не удалилось ничего.
Сначала пользователь удивится почему это ничего не удалилось, ведь он правильно всё выбрал.
Потом он удивится, когда увидит, что данных действительно больше нет.
И в третий раз удивится, когда начнёт искать в журнале/логе кто там его данные удалил и увидит, что это он.
А разработчики потом будут искать отличный баг про неправильное сообщение пользователю.

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

K>Так если я не получу ответ от сервера, то клиент повторно ему запрос на удаление отправит, когда связь восстановится \

И сразу получит 404. А теперь поясни — зачем тебе на клиенте понадобилось знать, удалил ли ты реально или все уже удалено?

K>Кроме удаления по ИД, может быть и удаление по какому-нибудь условию

Удаление по id это тоже удаление по условию, никакой разницы.

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

S>1 запрос — пароль1, пароль2. Ок, поменяли.
S>2 такой же запрос — пароль1, пароль2 — уже не пройдет, т.к. новый пароль — это пароль2 (был установлен на предыдущем шаге).

Будет ошибка, но состояние то сервиса не поменяется. Значит идемпотентность сохраняется и можно использовать PUT.

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

НС>И сразу получит 404. А теперь поясни — зачем тебе на клиенте понадобилось знать, удалил ли ты реально или все уже удалено?

Для информирования пользователя о том, чего он натворил, а чего без него успел кто-то понаделать.
Это не обязательное поведение и то и то допустимо, лишь бы человеки понимали особенности.

НС>Удаление по id это тоже удаление по условию, никакой разницы.

ну, при удалении людей старше 35 лет, метод вряд ли будет бросать 404, т.к. не указывалась конкретная запись.
Скорее всего, будет всегда кидать 200.

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

vsb>Почему бы первому DELETE не возвращать 200, а последующим 404? Вроде это ничему не противоречит. А то, что код возврата разный, ну и что.
vsb>Да и как вообще реализовать DELETE, который будет возвращать 200 на удалённый ресурс? Это из базы нельзя ничего удалять?

Soft-delete сделать какой-нибудь.

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

P>>На самом деле если абстрагироваться от хттп
НС>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.

Здесь мы обсуждаем http POST. REST как раз можно и без http применять.

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

НС>В мидлвере.

Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли. А так будет явный вызов.

P>>Идемпотентность это свойство прежде всего бизнес-операции.

НС>Однако обеспечение этой идемпотентности при помощи отдельного ключа — штука весьма универсальная, и не нужно ее копипастить в бизнес-коде по всем идемпотентным методам.

Копипастить и не нужно. Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.

То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару, если можно одной строчкой указать. И отлаживать проще, и отслеживать, и смена транспорта не повлечет тотальное переписывание

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

НС>>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.
P>Здесь мы обсуждаем http POST.

Нет, именно REST.

НС>>В мидлвере.
P>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.

Абалдеть логика. И часто у вас мидлвары подламывают или не подключают? А то, знаешь ли, та же аутентификация и авторизация тоже в виде мидлвар сделаны. Если такое можно подломать — не представляю как вы вообще разработку ведете.

P>>>Идемпотентность это свойство прежде всего бизнес-операции.
НС>>Однако обеспечение этой идемпотентности при помощи отдельного ключа — штука весьма универсальная, и не нужно ее копипастить в бизнес-коде по всем идемпотентным методам.
P>Копипастить и не нужно.

Нужно. Как минимум прописать это в модели, а потом из модели достать и куда то засунуть.

P> Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.

Для этого достаточно просто атрибут на метод навесить.

P>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару

Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

P>И отлаживать проще, и отслеживать,

Чем проще?

P> и смена транспорта не повлечет тотальное переписывание

Смена транспорта RESTful сервиса? Это какие то сказки. Если только на gRPC, но при этом отличия от HTTP будут минимальны.

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

НС>>>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.
P>>Здесь мы обсуждаем http POST.

НС>Нет, именно REST.

Смотри прямо заголовок — там POST, т.е. метод http. Если обсуждается именно Рест, то его надо обсуждать в отрыве от какого либо транспортного протокола.

P>>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.

НС>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?

Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

> А то, знаешь ли, та же аутентификация и авторизация тоже в виде мидлвар сделаны. Если такое можно подломать — не представляю как вы вообще разработку ведете.

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

P>>Копипастить и не нужно.
НС>Нужно. Как минимум прописать это в модели, а потом из модели достать и куда то засунуть.

Я показал, как это всё прописывать. Вместо атрибута будет параметр. Количество кода примерно одно и то же, только связывание в одном случае неявно, магией, через атрибуты, или явное, через вызов функции.
При этом для разных операций обеспечение идемпотентности может быть тупо разным.

P>> Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.
НС>Для этого достаточно просто атрибут на метод навесить.

Спасибо Кэп, я именно это показал двумя постами назад.

P>>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару
НС>Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

Энвелоп у вас еще не изобрели?

P>>И отлаживать проще, и отслеживать,
НС>Чем проще?

Можно писать тесты ниже уровнем, дешевые, быстрые.

P>> и смена транспорта не повлечет тотальное переписывание

НС>Смена транспорта RESTful сервиса? Это какие то сказки. Если только на gRPC, но при этом отличия от HTTP будут минимальны.

Именно. Смена транспорта это вобщем норма на большом промежутке времени. Бывает и на grapql переходят, и на grpc, и на что угодно. Проще явно ввести этот энвелоп.
Все что можно вынести в мидлвару — синхронизацию поля в энвелопе со значением хидера для http, на случай если придется это как то учитывать в каком гатевее.

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

P>>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару
НС>Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.

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

НС>>Нет, именно REST.
P>Смотри прямо заголовок — там POST, т.е. метод http.

Это серия постов от Шымжи, про REST. И по ссылке про REST. Поэтому все что я написал написано про REST, и попытки натянуть это на другие протоколы — скажем так, некорректны.

P>Если обсуждается именно Рест, то его надо обсуждать в отрыве от какого либо транспортного протокола.

REST в принципе не надо обсуждать в отрыве от протоколов, это противоречит его кулючевому принципу.

P>>>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.
НС>>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?
P>Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

Не только у нас изобрели способ вынести инфраструктурную часть сервиса в библиотеку, и любой новый проект просто ее подключает. Без ее подключения ничто никуда не полетит, а с ней автоматом будут все нужные мидлверы.

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

НС>REST в принципе не надо обсуждать в отрыве от протоколов, это противоречит его кулючевому принципу.

Ровно наоборот. Рест — принцип, архитектурный стиль. http — протокол, который хорошо подходит для restful систем.

НС>>>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?
P>>Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

НС>Не только у нас изобрели способ вынести инфраструктурную часть сервиса в библиотеку, и любой новый проект просто ее подключает. Без ее подключения ничто никуда не полетит, а с ней автоматом будут все нужные мидлверы.

Вы изобрели способ вытолкнуть бизнес-логику в инфраструктуру. Вот про это я и говорю.

Забавно, этим летом у меня был доклад про разработку фремворка и отношение к нему продуктовых разработчиков:

Product developer always request adding their business logic into your framework.

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

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

P>Ровно наоборот. Рест — принцип, архитектурный стиль.

И один из ключевых принципов этого стиля — по максимуму использовать существующие абстракции HTTP. Ты же тут пропагандируешь прямо противоположное.

P>Вы изобрели способ вытолкнуть бизнес-логику в инфраструктуру.

Это вопрос выбора точки зрения, является ли идемпотентность частью бизнес-логики или нет.

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

S>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.

Не вижу логики, что это обязательно именно требование к BL. С т.з. именно бизнес-логики — в систему приходит заказ и он должен быть обработан. Заказ должен как-то корректно поступить в систему — и тут начинается логика обработки заказа.

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

Идемпотентность операций при REST-запросах вполне можно трактовать как чисто техническое решение для технических проблем вида разрыва соединения, плохой связи и подобного, не имеющих прямого отношения к собственно логике бизнеса.

Хотя в каких-то случаях логика проверки дубликатов может быть важной частью бизнес-процесса, хотя скорее там будет описан не синтетический ключ идемпотентности, а какие-то правила сравнения по данным, которые позволяют считать разные сущности одинаковыми.

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

S>>1 запрос — пароль1, пароль2. Ок, поменяли.
S>>2 такой же запрос — пароль1, пароль2 — уже не пройдет, т.к. новый пароль — это пароль2 (был установлен на предыдущем шаге).
НС>Будет ошибка, но состояние то сервиса не поменяется. Значит идемпотентность сохраняется и можно использовать PUT.
С т.з. безопасности такой подход — дыра. Несовпадение пароля должно трактоваться как неуспешная попытка аутентификации и инкремировать счётчик, блокируя аккаунт при переполнении. Иначе API смены пароля будут использовать для подбора паролей.
Полагаю, правильным подходом будет попробовать пароль2, если пароль1 не сработал и просто отвечать ОК если пароль2 подошел.

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

P>>Ровно наоборот. Рест — принцип, архитектурный стиль.

НС>И один из ключевых принципов этого стиля — по максимуму использовать существующие абстракции HTTP. Ты же тут пропагандируешь прямо противоположное.

Так он был определен. Тем не менее, все теории развиваются, т.к. они и сами меняют реальность, и сами меняются вслед за изменениями реальности. РЕСТ ничем не лучше. Как только в широком доступе стало больше одного протокола, рест подход распространился и на них. нет никакой проблемы сделать ровно то же и на graphql, и на grpc, и вебсокетах, итд итд.

P>>Вы изобрели способ вытолкнуть бизнес-логику в инфраструктуру.

НС>Это вопрос выбора точки зрения, является ли идемпотентность частью бизнес-логики или нет.

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

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

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

S>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.

F>Не вижу логики, что это обязательно именно требование к BL.

Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
Это БЛ. Все остальное есть просто реализация вот такого требования.

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

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

S>>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.
F>>Не вижу логики, что это обязательно именно требование к BL.

P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.

Это бизнес-требование, которое может быть реализовано как идемпотентной операцией, так и без всякой идемпотентности (например так, что первое обращение списывает деньги и меняет состояние заказа и возвращает чек, второе дает ошибку, меняет внутренний счетчик попыток оплаты, отсылает СМС, и возвращает ошибку — совсем неидемпотентная операция, которая, однако, закроет вот этот требование единичной оплаты).

Требования могут быть реализованы как часть бизнес-логики, так и в целом техническим стеком вне этой логики. Например, бизнесу так же может требования консистентное сохранение данных заказа, но я могу не реализовывать транзакционность вручную в бизнес-логике, а использовать СУБД, в которой эта поддержка уже есть.

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

НС>>И один из ключевых принципов этого стиля — по максимуму использовать существующие абстракции HTTP. Ты же тут пропагандируешь прямо противоположное.
P>Так он был определен. Тем не менее, все теории развиваются

Это основополагающий принцип. Если от него отказаться, это уже будет совсем не REST.

P>>>Вы изобрели способ вытолкнуть бизнес-логику в инфраструктуру.
НС>>Это вопрос выбора точки зрения, является ли идемпотентность частью бизнес-логики или нет.
P>Изначально идемпотентность нужна для бизнес-логики.

Нет. Ты RFC то читал? Там ясно прописана цель — обеспечить отсутствие дублей при ретраях. Это — не бизнес логика, это инфраструктурная логика для борьбы с ненадежностью канала передачи.
Я тебе больше скажу, при использовании решений типа istio эта логика с клиентской стороны вообще физически уезжает из бизнес-кода в отдельный инфраструктурный контейнер. Что характерно, как раз благодаря тому, что абстракции уровня HTTP в REST не игнорируются, и содержимое на уровне HTTP обладает достаточной семантикой чтобы обеспечить довольно сложные вещи типа кеширования или ретраев находясь на уровне HTTP и ничего не зная про бизнес-логику. Если же ты абстрагируешься от протокола, такие решения станут невозможными.

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

S>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.
F>Не вижу логики, что это обязательно именно требование к BL. С т.з. именно бизнес-логики — в систему приходит заказ и он должен быть обработан. Заказ должен как-то корректно поступить в систему — и тут начинается логика обработки заказа.
F>И наоборот, логика проверки ключа идемпотентности может быть совершенно одинаковой как при заказе такси, так и при переключении канала трансляции на коммутаторе, хотя с т.з. бизнеса это совершенно разные бизнес-процессы из совершенно разных областей.
F>Идемпотентность операций при REST-запросах вполне можно трактовать как чисто техническое решение для технических проблем вида разрыва соединения, плохой связи и подобного, не имеющих прямого отношения к собственно логике бизнеса.
F>Хотя в каких-то случаях логика проверки дубликатов может быть важной частью бизнес-процесса, хотя скорее там будет описан не синтетический ключ идемпотентности, а какие-то правила сравнения по данным, которые позволяют считать разные сущности одинаковыми.

С тем что выше я спорить не буду. Но почему иногда, в отдельных случаях, важность идемпотентности для BL
не манифестировать на уровне типов, т.е. доп. параметр? Прям важно, чтобы клиент это осознавал, что не отменяет
возможность все это решать на уровне middleware.

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

S>С тем что выше я спорить не буду. Но почему иногда, в отдельных случаях, важность идемпотентности для BL
S>не манифестировать на уровне типов, т.е. доп. параметр? Прям важно, чтобы клиент это осознавал, что не отменяет
S>возможность все это решать на уровне middleware.

Когда надо — тогда стоит делать.

Собственно, я там выше по топику и говорил, что обощенная middleware не отменяет возможности в отдельных случаях делать особым образом, там где это действительно необходимо, и не тратить силы на повтор одного и того же там где можно обойтись стандартным шаблонным вариантом.

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

S>Минус очевидный — это диктует тип ключей — только UUID. А если хочется чтобы ключи генерила СУБД и там спец. система для распределенной генерации ключей? Т.е. такой PUT как бы обязывает применять новую схему создания ключей.

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

Однако можно сделать ключом крипто-хеш от содержимого записи, приведя ее сначала в вид, не зависящий от вариантов форматирования и порядка полей в объекте.

S>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.

Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.

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

Pzz>Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.
9.1.2 Idempotent Methods

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

Pzz>>Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.
S> 9.1.2 Idempotent Methods

Ну ОК. В спецификации есть.

Здравствуйте, Pauel, Вы писали:
P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.
Позволю себе не согласиться. Бизнес-аналитики вообще не должны мыслить вот этими категориями технических подробностей.
Есть бизнес-сценарий. Например — заказ такси.
Бизнес аналитик в первую голову анализирует функциональные потребности. Ну там — будем ли мы в рамках одного заказа давать ехать через N точек, или это строго A->Б?
Можно ли разделить оплату на нескольких пассажиров, или мы требуем строго 1 поездка = 1 плательшик?
А одному плательщику можно оплатить заказ частично картой, частично кэшем? А двумя картами?
Можно ли отменить заказ? А если водитель уже приехал? А если начал выполнение заказа?
Что делать, если клиент не выходит, но заказ не отменяет?
В какой момент списывать деньги — в начале поездки? В конце? Что, если поездка прервана посередине?

В первую голову, естественно, идут т.н. "позитивные" сценарии.
Потом начинаем критически смотреть на это — нет ли в нашей бизнес-логике дырок. Типа: таксист никуда не поехал, а тупо нажал "я прибыл", дождался "невыхода" клиента, получил компенсацию от сервиса, и побежал "брать" другой заказ. Или, например, наоборот — клиент вызывает такси, и за 30 секунд до прибытия машины отменяет заказ, и так 100 раз.
Или мы списали с клиента 100р за первый сегмент, начинаем списывать 500 за второй — а у нас отказ банка.

Изо всего этого строится большое-большое дерево решений; на их основе формируется набор требований.
Вот эти все подробности "ой, а что делать, если во время поездки рубануло питание датацентра?" — это вообще не вопрос бизнес-логики. Бизнес-аналитик (по крайней мере, в нормальной компании) не должен объяснять solution architect вещи типа "ребяты, надо все изменения держать в персистентной СУБД, и вся интеграция с внешними сервисами должна уметь восстанавливаться после сбоя".
И точно так же вопросы идемпотентности конкретных методов находятся в ведении архитекторов.
Это то же самое, как если бы аналитик должен был в каждом use-case добавлять строчку "а ещё программа должна работать корректно".
Или, к примеру, диктовал, какой протокол выбирать.
Если бы BA проектировал сервис типа DNS, то он бы наверняка большое внимание уделил таким вещам, как семейства записей и топология доменных зон.
Вещи типа TTL уже обсуждались между BA и архитекторами, которые бы объясняли, что для обеспечения нужного уровня надёжности база должна быть распределена, поэтому прямое управление кэшированием лучше игры в угадайку.
В процессе обсуждения в бизнес-логику проникли бы концепции вроде авторитативных и не-авторитативных ответов.
А вот вещи типа выбора UDP вместо TCP в качестве протокола, а также детали того, как клиент понимает, какой из пакетов ответа относится к какому запросу, вообще бы целиком решались на уровне архитекторов.
Это нифига не часть "бизнес-логики". Бизнес-логика там ровно та же, что и в HTTP — есть запрос, есть ответ. А вот какие конкретно будут методы в HTTP, или коды ошибок, или структура и нумерация UDP-пакетов — это слишком низкий для BL уровень.

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

S>Это нифига не часть "бизнес-логики". Бизнес-логика там ровно та же, что и в HTTP — есть запрос, есть ответ. А вот какие конкретно будут методы в HTTP, или коды ошибок, или структура и нумерация UDP-пакетов — это слишком низкий для BL уровень.

Хорошо, я согласен, идемпотентность не относится к бизнес-логике.
Вот у нас есть два варианта реализации операции, что выберешь?

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

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

Магический

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

Здравствуйте, 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), из тела, или из какого-то хидера. Прикладному сервера это всё равно, а вот с точки зрения клиентов и, в том числе, совместимости между разными версиями протокола это может быть важно.

Здравствуйте, 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.

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

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

Всех участников

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

POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.

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

При чем здесь json patch и почему какая с ним проблема?

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

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

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

P>Всех участников
И как клиент может проконтролировать?


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

P>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным

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

P>При чем здесь json patch и почему какая с ним проблема?
При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

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

P>>Всех участников
G>И как клиент может проконтролировать?

Клиенту нужно выполнить свои обязанности

P>>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
G>Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным

Из описания API. Обычно клиент генерируется, а не пишется руками.

P>>При чем здесь json patch и почему какая с ним проблема?
G>При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?

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

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

P>>>Всех участников
G>>И как клиент может проконтролировать?
Какие обязанности у клиента?

P>Клиенту нужно выполнить свои обязанности

P>>>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
G>>Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным
P>Из описания API. Обычно клиент генерируется, а не пишется руками.
В каком описании присутствует информация об идемпотентности тех или иных вызовов?


P>>>При чем здесь json patch и почему какая с ним проблема?
G>>При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

P>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный. еЕли мы повторяем вызовы, то порядок выполнения не будет совпадать с изначальным порядком вызовов.

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

P>>>>Всех участников
G>>>И как клиент может проконтролировать?
G>Какие обязанности у клиента?

Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.

P>>Из описания API. Обычно клиент генерируется, а не пишется руками.
G>В каком описании присутствует информация об идемпотентности тех или иных вызовов?

Я привел описание, вернись и посмотри. Выглядит так, будто ты накидываешь не читая.

P>>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
G>Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный.

Что мешает зафиксировать этот порядок или вообще убрать эти add-remove-copy?

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

Как то странно выполнять приседания пачкой каждый раз. Если хочешь, что бы батч, а add-remove-copy, это фактически батч, был идемпотентным, то надо приложить чуть больше усилий, чем просто выполнять каждый раз и ждать того же результата.
Например, порядок должен быть зафиксирован, эта пачка операций идет внутри транзакции, и выполняется ровно один раз, не больше, и не меньше. Отсюда не ясно, как ты собиаешься получить "разный" результат.

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

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

G>>>>И как клиент может проконтролировать?
G>>Какие обязанности у клиента?
P>Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.
Какие метаданные сообщают клиенту что операция идемпотента?

G>>В каком описании присутствует информация об идемпотентности тех или иных вызовов?
P>Я привел описание, вернись и посмотри. Выглядит так, будто ты накидываешь не читая.
Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.

P>>>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
G>>Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный.
P>Что мешает зафиксировать этот порядок или вообще убрать эти add-remove-copy?
P>Как то странно выполнять приседания пачкой каждый раз. Если хочешь, что бы батч, а add-remove-copy, это фактически батч, был идемпотентным, то надо приложить чуть больше усилий, чем просто выполнять каждый раз и ждать того же результата.
P>Например, порядок должен быть зафиксирован, эта пачка операций идет внутри транзакции, и выполняется ровно один раз, не больше, и не меньше. Отсюда не ясно, как ты собиаешься получить "разный" результат.
Это уже правильный путь. Если сделать несколько шагов, то получится PUT на урл с ключом и полным "объектом" в теле, без всяких дельт.

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

F>Это можно сделать каким-то промежуточным слоем, который будет отрабатывать для всех запросов вообще и одинаково. Но значение ключа при этом тогда гораздо удобнее держать не частью бизнес-данных запроса, а чем-то техническим — хидер для rest, или поле в конверте, например, если у нас какой-то свой протокол.

F>При появлении нового запроса в АПИ достаточно будет прописать тот же хидер и вся магия для него заработает сразу, без каких-то правок. А если уж вдруг для каких-то запросов "стандартный" механизм не подходит, то убрать этот общий хидер и делать отдельно на урвоне бизнес-логики.

Да, тут вопрос в некоторой мета-договорённости. Для PUT такая мета-договорённость присутствует в самом протоколе, почему он и крут. Для всего остального надо привинчивать ручками.
Для меня это выглядит некоторым аналогом авторизации. Вот у нас сейчас стандартом де-факто является авторизационный токен, который передаётся в хидере Authentication.
При этом лично у меня нет никакого желания делать его явным параметром метода бизнес-логики.
Бизнес-аналитик пишет в требованиях "этот метод требует наличия роли XXX у вызывающего". И логично это описывать в виде каких-то аннотаций на метод на стороне сервера, а не делать явный параметр authenticationToken, который потом реализатор должен как-то обработать прикладным кодом.

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

P>>Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.
G>Какие метаданные сообщают клиенту что операция идемпотента?

Например, атрибут @Idempotent() над определением операции. Или обязательный параметр idempotency key который помечет соответствующим атрибутом.
Все что нужно от клиента — одинаковые параметры должны давать тот же самый реквест вне зависимости от последовательности вызовов.

G>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.

А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.

G>Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.

В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.

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

Совсем необязательно. Идемпотентность нужна вне зависимости от транспорта. Т.е. может оказаться так, что нет ни post, ни put, ни вообще http, а REST и идемпотентность операции остаются.
Сейчас в норме сервсисы унутре конторы коммуницируют не только через http. Зачем мастырит чтото особенное, если для той же декларации АПИ можно просто подкинуть другой транспорт?
И клиентский, и серверный код останутся без изменений.
Даже если ты перейдешь на graphql, это не избавит тебя от обеспечения идемпотентности.

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

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

G>>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
P>А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.
Это описание в каком формате?
Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?


G>>Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.
P>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

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

G>>>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
P>>А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.
G>Это описание в каком формате?

Ключ идемпотентности в любом описании апи это явный обязательный параметр. Какая именно проблема у тебя тут возникла?

G>Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?

Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.

P>>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
G>Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?

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

P>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

P>Какая именно проблема у тебя тут возникла?
Проблема определения ключа идемпотентности

G>>Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?
P>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.

P>>>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
G>>Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

P> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.

P>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.

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

P>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
Нет. В PUT ключом идемпотентности выступает ровно URL ресурса. Так описано в спеке на HTTP.

P>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
Проблема — в том, что семантика рукопашного ключа идемпотентности описана где-то в тексте, который нужно прочитать глазами, и реализовать паттерн идемпотентного доступа руками.
В одном АПИ ключ поедет в хидере, в другом АПИ — в теле, в третьем — вовсе придумают его в query string.

P> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
Нет, но клиент может полагаться на идемпотентность PUT в силу RFC 2616.

P>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
А вы уже посмотрели, как именно операции делаются идемпотентными в той же ODATA?

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

P>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
G>И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

А как ты определяешь, что параметр является именем пользователя, идентификатором, емейлом, суммой для списания со счета?
А correlation ты как определяешь?

P>>Какая именно проблема у тебя тут возникла?
G>Проблема определения ключа идемпотентности

Ровно то же самое, что и с аргументом любой другой семпантики.

G>Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.

Ужос, и исходный код я тоже не выкладываю!!!!!11111йййqqq Все ответы дадены. У тебя по существу пока ничего нового нет.

P>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
G>В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.

Правильно понимаю, то самое "соглашение высокого уровня" само себя запроектирует, закодит, зафиксит баги, протестирует, продеплоит и всё само себя?

P>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
G>Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.

Так и есть — PUT сам себя обеспечит гарантиями, доведет до прода сам себя, да еще и баги от юзеров сам будет репортать.

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

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

P>>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
G>>И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

P>А как ты определяешь, что параметр является именем пользователя, идентификатором, емейлом, суммой для списания со счета?
По имени параметра. Ты предлагаешь тоже по имени это делать?

P>А correlation ты как определяешь?
Это что?

P>>>Какая именно проблема у тебя тут возникла?
G>>Проблема определения ключа идемпотентности
P>Ровно то же самое, что и с аргументом любой другой семпантики.
Нет, ключом идемпотентности в PUT и DELETE является url


G>>Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.
P>Ужос, и исходный код я тоже не выкладываю!!!!!11111йййqqq Все ответы дадены. У тебя по существу пока ничего нового нет.
Теперь понятно

P>>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
G>>В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.
P>Правильно понимаю, то самое "соглашение высокого уровня" само себя запроектирует, закодит, зафиксит баги, протестирует, продеплоит и всё само себя?
ни одно соглашение этого не сделает

P>>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
G>>Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.
P>Так и есть — PUT сам себя обеспечит гарантиями, доведет до прода сам себя, да еще и баги от юзеров сам будет репортать.
Так как odata сервис в основном пишется людьми, которые читали RFC, то ты можешь рассчитывать, что PUT и DELETE там будут идемпотентными, а POST — не будет. Это еще до получения edmx.
Более того, даже если сделают какой-то метод в edmx, который будет вызываться с помощью POST и будет идемпотентен, то ты об этом не узнаешь, потому что в EDMX нет этой информации.
Кроме случаев если в параметрах метода явно написан idempotencyKey, но тогда непонятно почему бы не вынести этот ключ в url и не использовать PUT.

Короче снова пришли к тому, что идемпотентность POST в общем случае не нужна и приседания с её реализацией не имеют смысла.

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

P>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
S>Нет. В PUT ключом идемпотентности выступает ровно URL ресурса. Так описано в спеке на HTTP.

Урл нам надо сначала отрендерить
Вот PUT в ODATA протоколе, который REST искаропки

PUT /Warehouse.svc/Orders('an-id')

Вызываем его примерно так:

svc.orders.update('an-id', modifiedOrder);

или так:

svc.orders.update(modifiedOrder);

Т.е. у нас явный параметр, который и будет ключом идемпотентности. Для POST мы этот ключ можем положить куда угодно, это непринципиально.

P>>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
S>Проблема — в том, что семантика рукопашного ключа идемпотентности описана где-то в тексте, который нужно прочитать глазами, и реализовать паттерн идемпотентного доступа руками.
S>В одном АПИ ключ поедет в хидере, в другом АПИ — в теле, в третьем — вовсе придумают его в query string.

Куда поедет ключ — дело десятое. Есл клиент генерируется по метаданным, а наружу торчит OO-интерфейс, нам это вообще по барабану, где что лежит. Вылезла пробелема с гатевеем, которй не пропускает наш запрос — поменяли атрибут, добавили @Header или @Encode и всё путём — перебилдили, и всё палит. Не надо вообще думать, что там где на самом деле лежит.

P>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
S>Нет, но клиент может полагаться на идемпотентность PUT в силу RFC 2616.

Клиент — может. А на сервере это нужно мейнтейнить руками. Например, какой то шутник решит, что раз изменений нету, то можно и ошибку бросить "already done". И тесты надо написать, что бы такой шутник убедился, что его подход невалидный.

P>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
S>А вы уже посмотрели, как именно операции делаются идемпотентными в той же ODATA?

Что касается одаты, то я запилил серверный фремворк для TypeScript поверх оdata протокола собственной разработки, так что вобщем одату понимаю. Кое что портироал на жээс из odata-olingo, кое что из дотнета, остальное допилил самостоятельно. Собственно, это мой текущий проект — кучка фремворков на разные случаи жизни.
Идемпотентность реализуется ровно так же, как и везде. И на graphql нам она тоже нужна, и на grpc тоже. Например, апи будет торчать — openapi, odata, graphql, grpc. Незачем мучиться и пилить всё под каждый протокол. У нас только контроллеры будут разные, а всё остальнео будет в общем коде, и там же идемпотентность будет сидеть.
Вот например кейс такой, что нам надо проавать апи и юезр будет выбирать протокол и платить за количество фактически вызваных операций. А он возьми и выбери graphql. Разве мы ему скажем, что теперь про идемпотентность он должен забыть?

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

P>>А как ты определяешь, что параметр является именем пользователя, идентификатором, емейлом, суммой для списания со счета?
G>По имени параметра. Ты предлагаешь тоже по имени это делать?

Я предлагаю вернуться и посмотреть то самое определение апи, которое ты счел несущественным. Сейчас мы просто пересказываем ровно то, что там проиллюстрировано.

P>>А correlation ты как определяешь?
G>Это что?



P>>Ровно то же самое, что и с аргументом любой другой семпантики.
G>Нет, ключом идемпотентности в PUT и DELETE является url

Ога. А в url будет id объекта, который ты хочешь удалить или перезаписать. То есть, явный параметр. Ты что, запросы из терминала шлёшь, набивая их руками?

P>>Правильно понимаю, то самое "соглашение высокого уровня" само себя запроектирует, закодит, зафиксит баги, протестирует, продеплоит и всё само себя?
G>ни одно соглашение этого не сделает

Ужос! Это что же — ты в курсе как имплементать идемпотентность, но вопрошаешь будто бы не в курсе дел?

G>Более того, даже если сделают какой-то метод в edmx, который будет вызываться с помощью POST и будет идемпотентен, то ты об этом не узнаешь, потому что в EDMX нет этой информации.

В edmx есть аннотации, куда ты можешь класть всё что тебе надо. Главное, что бы твой генеренный код протаскивал все нужные параметры как на клиенте, так и на сервере.

G>Кроме случаев если в параметрах метода явно написан idempotencyKey, но тогда непонятно почему бы не вынести этот ключ в url и не использовать PUT.

Потому, что один клиент хочет транспорт graphql, второй — odata, третий grpc, четвертый обычный openapi.

G>Короче снова пришли к тому, что идемпотентность POST в общем случае не нужна и приседания с её реализацией не имеют смысла.

Мы снова пришли к примеру операции в odata протоколе, или grapql, или grpc. Идемпотентность нужна, а вот Put и даже http может и не быть.

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

P>Урл нам надо сначала отрендерить
Эта фраза непонятна.
P>Вот PUT в ODATA протоколе, который REST искаропки
P>

P>PUT /Warehouse.svc/Orders('an-id')
P>

Всё верно. 'an-id' является частью URL.

P>Вызываем его примерно так:
P>

P>svc.orders.update('an-id', modifiedOrder);
P>

P>или так:
P>

P>svc.orders.update(modifiedOrder);
P>

P>Т.е. у нас явный параметр, который и будет ключом идемпотентности.
Нет. В первую очередь этот параметр — часть навигации.
В частности, мы можем сделать GET /Warehouse.svc/Orders('an-id') и получить этот ордер обратно.
То, что этот 'an-id' является ключом идемпотентности, следует не из какой-то особенной магии OData, а из спецификации HTTP.
Поэтому мы можем между клиентом и сервером воткнуть прокси, который будет, скажем, задерживать респонс случае получения невнятного ответа от апстрима, и продолжать долбить этот апстрим повторяющимися PUT-ами до получения вменяемого ответа — даже если сам клиент ничего не знает про возможности повторных запросов.
P>Для POST мы этот ключ можем положить куда угодно, это непринципиально.
Принципиальна возможность как-то донести до клиента или прокси информацию о том, что изо всего букета POST является ключом идемпотентности.


P>Куда поедет ключ — дело десятое. Есл клиент генерируется по метаданным, а наружу торчит OO-интерфейс, нам это вообще по барабану, где что лежит. Вылезла пробелема с гатевеем, которй не пропускает наш запрос — поменяли атрибут, добавили @Header или @Encode и всё путём — перебилдили, и всё палит. Не надо вообще думать, что там где на самом деле лежит.
Это какая-то утопия. Покажите мне гатевей, который путём перебилдивания осознает, что какой-то там кусок квери стринга является на самом деле ключом идемпотентности, и сможет делать авто-повторы от имени тупых клиентов, как я показал выше.

P>Клиент — может. А на сервере это нужно мейнтейнить руками.
В этом смысле все подходы равноценны — можно вообще свой собственный глагол замутить, типа CREATE (чтобы не путаться с PUT, который то ли "создать", то ли "изменить").
Всё равно "всё это нужно мейнтейнить руками".

P>Например, какой то шутник решит, что раз изменений нету, то можно и ошибку бросить "already done". И тесты надо написать, что бы такой шутник убедился, что его подход невалидный.
Ну, с тем же успехом шутник может просто на всё возвращать 200 OK, не записывая ничего в базу. Какое отношение это имеет к проектированию?

P>Что касается одаты, то я запилил серверный фремворк для TypeScript поверх оdata протокола собственной разработки, так что вобщем одату понимаю. Кое что портироал на жээс из odata-olingo, кое что из дотнета, остальное допилил самостоятельно. Собственно, это мой текущий проект — кучка фремворков на разные случаи жизни.
P>Идемпотентность реализуется ровно так же, как и везде.
Из ваших слов я делаю вывод, что официальные рекомендации вы не читали.
Потому как в ODATA она всё же не такая, как везде.

P>Вот например кейс такой, что нам надо проавать апи и юезр будет выбирать протокол и платить за количество фактически вызваных операций. А он возьми и выбери graphql. Разве мы ему скажем, что теперь про идемпотентность он должен забыть?
Мы с вами, похоже, говорим о разных вещах. Идемпотентность сама по себе является практически единственным способом построения нормальных распределённых приложений.
Понятно, что гольным HTTP мир не исчерпывается; можно оказаться в чистом поле какого-нибудь RPC или вообще низкоуровневого протокола типа TCP, для которого никто о таких вещах и не планировал задумываться.
Там, понятное дело, мы будем городить идемпотентность из палок и верёвок. Ровно как и дельта-енкодинг, кондишнл геты, кондишнл апдейты (они же оптимистик локинг) и прочие небезынтересные штуки.

Но в случае наличия HTTP имеет смысл как можно больше пользоваться уже разработанными спецификациями. В частности потому, что к ним более-менее готовы все существующие инструменты.
А когда вы выходите в чистое поле, то вы и биться там будете один. Можно посмотреть на богомерзкий SOAP, где пошли ровно по этому пути. Когда чтение какого-нибудь Order делается тоже через POST, а идентификатор уезжает в теле. Ну и всё — пришлось громоздить чудовищную гору всех этих полунеобязательных и слабосовместимых WS-* спецификаций, чтобы закатить солнце вручную.

Хорошо, что мы от этого ушли в сторону REST.

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

P>>Урл нам надо сначала отрендерить
S>Эта фраза непонятна.

С т.з. разработчика урл составляется из разных кусков, у которых разная семантика, эти куски и есть фактически параметры.

S>Всё верно. 'an-id' является частью URL.

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

S>В частности, мы можем сделать GET /Warehouse.svc/Orders('an-id') и получить этот ордер обратно.

А что это меняет? Гарантии то всё равно слабые. Лучше подкинуть хидер prefer и получить результат в выхлопе post.

P>>Для POST мы этот ключ можем положить куда угодно, это непринципиально.
S>Принципиальна возможность как-то донести до клиента или прокси информацию о том, что изо всего букета POST является ключом идемпотентности.

Да, для http POST мы не сможем ничего такого сделать, т.к. прокси сверх хттп ничего не понимает. Зато мы можем сделать свой прокси для нашего сервиса, и он сможет обеспечить все, что нужно. Можно и graphql прокси точно так же примастырить, и все будет путём.

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

Теоретически это круто, авто-повторы от имени сверх-тонких клиентов, но практически это лучше делать через гатевей, который понимает тот протокол, который поверх хттп. Тогда к нему можно прикрутить кучку дополнительных вещей.

P>>Например, какой то шутник решит, что раз изменений нету, то можно и ошибку бросить "already done". И тесты надо написать, что бы такой шутник убедился, что его подход невалидный.
S>Ну, с тем же успехом шутник может просто на всё возвращать 200 OK, не записывая ничего в базу. Какое отношение это имеет к проектированию?

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

P>>Идемпотентность реализуется ровно так же, как и везде.
S>Из ваших слов я делаю вывод, что официальные рекомендации вы не читали.
S>Потому как в ODATA она всё же не такая, как везде.

Да, мы не поддерживаем эту фичу. Собственно, быстро глянул, они предлагают для всех unsafe методов добавлять доп хидеры, один из которых и будет тем самым ключом идемпотентности.
Т.е. внагрузку к урл, будет еще один ключ. Разумная вещь.

P>>Вот например кейс такой, что нам надо проавать апи и юезр будет выбирать протокол и платить за количество фактически вызваных операций. А он возьми и выбери graphql. Разве мы ему скажем, что теперь про идемпотентность он должен забыть?
S>Мы с вами, похоже, говорим о разных вещах. Идемпотентность сама по себе является практически единственным способом построения нормальных распределённых приложений.

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

S>Но в случае наличия HTTP имеет смысл как можно больше пользоваться уже разработанными спецификациями. В частности потому, что к ним более-менее готовы все существующие инструменты.

Я вот шота навскидку не могу представить, какой из сервисов-посредников поддерживает repeatable requests

S>Хорошо, что мы от этого ушли в сторону REST.

Как по мне, так bff/edge-services, graphql и grpc пожрали и рест, и одату целиком. Скажем, на собесах меня перестали спрашивать по рест лет 5 назад. А про одату товарищи только знают, что этото чтото дотнетное, и ни единого вопроса не задают. Подумаешь, мелочовочка — запилить full-blown серверный процессин, фремворк поверх этого, кодогенератор и тд.

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

G>Нет, ключом идемпотентности в PUT и DELETE является url
Не является. Нет в HTTP (и REST) никаких ключей идемпотентности. К одному URL может быть несколько разных запросов. И каждый из этих запросов может выполняться несколько раз. Поэтому идемпотентность (в том смысле, в котором она определена в HTTP) — это свойство именно операции.

Далее. Похоже, в этой теме есть непонимание того, что такое идемпотентность. Прямо по определению (RFC 2616, 9.1.2) идемпотентность говорит, что req(req(state)) == req(state) (и как следствие req(req(req(...(req(state))...))) == req(state). Всё! В общем случае оно даже не гарантирует, что сломавшийся запрос можно безопасно повторять. Причем об этом прямым текстом написано прямо в той же части про идемпотентность. Если у нас есть несколько акторов (субъектов, систем), оперирующих над одним ресурсом, могут наблюдаться различные неприятные эффекты. Например, система А делает PUT /variables/x с содержимым "1". Система Б читает это значение, выполняет какие-то операции, делает PUT /variables/x с содержимым "2". Затем система А повторяет запрос PUT /variables/x со значением "1". В результате система Б может опять обнаружить значение 1 и повторить свои (уже неидемпотентные) действия. И все усложняется тем, что в реальной системе акторов обычно много. Инфраструктура HTTP в виде балансировщиков нагрузки и маршрутизаторов тоже может выступать в качестве акторов. Например, она может приводить к задержкам запросов, что со стороны получателя может выглядеть как изменение порядка запросов от клиента. Поэтому на практике для обеспечения безопасных повторов нужно использовать дополнительные техники:

• Во многих случаях можно сделать конечный автомат без циклов. В этом случае перемещение в предыдущие состояния не допускается. Рудиментарная машина с ровно одним переходом (единственная операция — создание ресурса) является частным случаем такого автомата.
  
• В ряде сценариев можно выделить "главную" систему. Например, корзина (basket) в интернет-магазине может уведомлять склад (warehouse), который обновляет остатки. В этом случае корзина — главная система, владеющая информацией. Она всегда знает последнее состояние и уведомляет склад только этим состоянием. В условиях возможности переупорядочивания запросов в состояние/сообщение явно должен входить индикатор порядка (версия/ревизия или время последнего изменения). Конечного автомата здесь нет, но упорядоченность переходов все равно есть.
  
• Наше REST API является главной системой. Например, у нас внутренняя система (backoffice), в которой несколько менеджеров могут одновременно редактировать один заказ или его свойства. В этом случае обычно делается оптимистическая блокировка, которая на уровне HTTP выглядит в виде условных запросов (Conditional Requests). Обычно это If-Match (для существующих ресурсов) и X-If-Not-Exists/CREATE (для создания нового).

В самом HTTP для существующих глаголов есть два типа идемпотентности. Первый наблюдается у безопасных глаголов (GET/HEAD/OPTIONS). У них состояние ресурса не изменяется, т.е. req(state) == state. Второй тип наблюдается у глаголов PUT/DELETE. Для них выполняется семантика перезаписи. Если запрос применим в состояниях s1 и s2, то состояние после выполнения запроса одно и то же: req(s1) == req(s2). На практике для безопасного повторения запросов в системах со многими акторами хотелось бы больших гарантий. Например, req(req1(req2(...(reqN(req(state)))...))) == req1(req2(...(reqN(req(state)))...)) (т.е. если запрос был выполнен ранее, его повторение не приведет к изменению состояний). Готового глагола с такой семантикой нет. Но операции — есть. Например, движение по конечному автомату без циклов. В этом случае большинство запросов имеют семантику req(state) == max(state, newState). В этом случае повторное выполнение в любом состоянии будет безопасно.

Явный ключ идемпотентности (как в POST) в REST моделируется через команды и рудиментарный конечный автомат с ровно одной операцией (PUT с семантикой CREATE), доступной клиенту. Что-то вроде PUT /resources/xxx/operations/<unique-op-id>. Но, опять же, в данном случае требуемые свойства системы достигаются за счет того, как определен автомат. Технически ресурс может поддерживать больше операций. Например, поддерживать отмену запроса в виде глагола DELETE. И в этом случае можно создавать гонки между PUT/DELETE на одном ресурсе (с разным содержимым команд).

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

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

G>>Нет, ключом идемпотентности в PUT и DELETE является url
M>Не является. Нет в HTTP (и REST) никаких ключей идемпотентности. К одному URL может быть несколько разных запросов. И каждый из этих запросов может выполняться несколько раз. Поэтому идемпотентность (в том смысле, в котором она определена в HTTP) — это свойство именно операции.
Что такое "операция"? Видимо речь о запросе, запрос это Метод+URL+Тело+Заголовки
Предложение оппонента сделать "идемпотентность" по полю тела или заголовка.


M>Далее. Похоже, в этой теме есть непонимание того, что такое идемпотентность. Прямо по определению (RFC 2616, 9.1.2) идемпотентность говорит, что req(req(state)) == req(state) (и как следствие req(req(req(...(req(state))...))) == req(state). Всё! В общем случае оно даже не гарантирует, что сломавшийся запрос можно безопасно повторять.
Как раз гарантирует. В случае неполучения ответа (пропадания связи) или ответа 500 можно повторять идемпотентный запрос пока не получишь другой ответ.

M>Причем об этом прямым текстом написано прямо в той же части про идемпотентность. Если у нас есть несколько акторов (субъектов, систем), оперирующих над одним ресурсом, могут наблюдаться различные неприятные эффекты. Например, система А делает PUT /variables/x с содержимым "1". Система Б читает это значение, выполняет какие-то операции, делает PUT /variables/x с содержимым "2". Затем система А повторяет запрос PUT /variables/x со значением "1". В результате система Б может опять обнаружить значение 1 и повторить свои (уже неидемпотентные) действия.
Это к идемпотентности не имеет отношения. Это состояние гонки и с ним надо бороться другими методами.
Идемпотентность позволяет повторять запросы пока ты не получил ответа совсем (связи нет) или получил 500 (ошибка на стороне сервера). При получении любого другого ответа надо прекратить повторы.

M>И все усложняется тем, что в реальной системе акторов обычно много. Инфраструктура HTTP в виде балансировщиков нагрузки и маршрутизаторов тоже может выступать в качестве акторов. Например, она может приводить к задержкам запросов, что со стороны получателя может выглядеть как изменение порядка запросов от клиента. Поэтому на практике для обеспечения безопасных повторов нужно использовать дополнительные техники:
M>

M>
• Во многих случаях можно сделать конечный автомат без циклов. В этом случае перемещение в предыдущие состояния не допускается. Рудиментарная машина с ровно одним переходом (единственная операция — создание ресурса) является частным случаем такого автомата.
  M>
• В ряде сценариев можно выделить "главную" систему. Например, корзина (basket) в интернет-магазине может уведомлять склад (warehouse), который обновляет остатки. В этом случае корзина — главная система, владеющая информацией. Она всегда знает последнее состояние и уведомляет склад только этим состоянием. В условиях возможности переупорядочивания запросов в состояние/сообщение явно должен входить индикатор порядка (версия/ревизия или время последнего изменения). Конечного автомата здесь нет, но упорядоченность переходов все равно есть.
  M>
• Наше REST API является главной системой. Например, у нас внутренняя система (backoffice), в которой несколько менеджеров могут одновременно редактировать один заказ или его свойства. В этом случае обычно делается оптимистическая блокировка, которая на уровне HTTP выглядит в виде условных запросов (Conditional Requests). Обычно это If-Match (для существующих ресурсов) и X-If-Not-Exists/CREATE (для создания нового).
  M>

В общем случае только последнее имеет смысл. Только к идемпотентности не имеет отношения. Так как даже без повторения запросов можно получить эти проблемы. Кстати способ разрешения конфликтов в вебе был описан раньше REST https://www.w3.org/1999/04/Editing/


M>В самом HTTP для существующих глаголов есть два типа идемпотентности. Первый наблюдается у безопасных глаголов (GET/HEAD/OPTIONS). У них состояние ресурса не изменяется, т.е. req(state) == state. Второй тип наблюдается у глаголов PUT/DELETE. Для них выполняется семантика перезаписи.
Это называется SAFE и IDEMPOTENT


M>Явный ключ идемпотентности (как в POST) в REST моделируется через команды и рудиментарный конечный автомат с ровно одной операцией (PUT с семантикой CREATE), доступной клиенту. Что-то вроде PUT /resources/xxx/operations/<unique-op-id>. Но, опять же, в данном случае требуемые свойства системы достигаются за счет того, как определен автомат. Технически ресурс может поддерживать больше операций. Например, поддерживать отмену запроса в виде глагола DELETE. И в этом случае можно создавать гонки между PUT/DELETE на одном ресурсе (с разным содержимым команд).
Суть разговора была в том, что оппонент предлагает использовать POST и <unique-op-id> в теле или заголовке

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

M>>Явный ключ идемпотентности (как в POST) в REST моделируется через команды и рудиментарный конечный автомат с ровно одной операцией (PUT с семантикой CREATE), доступной клиенту. Что-то вроде PUT /resources/xxx/operations/<unique-op-id>. Но, опять же, в данном случае требуемые свойства системы достигаются за счет того, как определен автомат. Технически ресурс может поддерживать больше операций. Например, поддерживать отмену запроса в виде глагола DELETE. И в этом случае можно создавать гонки между PUT/DELETE на одном ресурсе (с разным содержимым команд).
G>Суть разговора была в том, что оппонент предлагает использовать POST и <unique-op-id> в теле или заголовке

Тут Синклер скинул ссылку на спеку Repeatable Request, вобщем, это оно и есть. Просто Shmj зашел слишком издалека.

Здравствуйте, Pauel, Вы писали:
P>Это и есть явный параметр. Гарантии ничтожные — если нет других реквестов, юзеров, итд, то реквест можно повторять и ждать того же реквеста. Но нам обычно надо побольше.
Эти гарантии замечательны тем, что хорошо известны всем клиентам — независимо от степени их обученности нашей самоизобретённой супер-технологии.
P>А что это меняет? Гарантии то всё равно слабые. Лучше подкинуть хидер prefer и получить результат в выхлопе post.
Речь не о том, что мы хотим сделать GET-после-PUT, а в некоторых мета-соглашениях об API.
Вот, к примеру, когда я вижу, что для создания нового экземпляра мне предлагается сделать POST на некий URL, у меня нет никакой информации о том, где я потом буду эту сущность запрашивать.
Ну да, обычно я могу увидеть список этих сущностей, выполнив GET на тот же URL. И тем не менее — не всегда понятно, чем именно адресуется конкретная сущность.
Никакие prefer тут не помогут.

P>Да, для http POST мы не сможем ничего такого сделать, т.к. прокси сверх хттп ничего не понимает. Зато мы можем сделать свой прокси для нашего сервиса, и он сможет обеспечить все, что нужно. Можно и graphql прокси точно так же примастырить, и все будет путём.

Вы рассуждаете в рамках модели, где и сервер и клиент пишутся вами.
Я же рассматриваю более широкий случай — когда мы пишем что-то одно. То есть либо мы пишем клиента к существующему сервису, либо пишем сервис для неопределённого круга клиентов.
У нас нет вот этой роскоши "поменять аннотацию и перекомпилировать гатевей", потому что мы вообще не контролируем вторую сторону.
Если мы вдруг решим перенести ключ идемпотентности из тела в хидер на стороне сервера, то это просто означает, что сколько-то тысяч клиентов упадут после деплоймента.

А когда мы пишем клиента, у нас возникает вопрос "а как узнать, что и как себя ведёт". Про требования идемпотентности PUT мы знаем из публичных RFC, поэтому пишем наш код соответствующим образом.
Для POST мы должны глазами читать спецификацию на естественном языке. Которая очень редко бывает исчерпывающей, кстати.
Обратите внимание, как замудрёно прикрутили идемпотентность POST к OData — там ещё и предусмотрен способ ограничить продолжительность обязанности сервера по поддержке идемпотентности.
Это придумали практики. Очень может так оказаться, что сервис, который анонсировал идемпотентность в спецификации, на самом деле способен её придерживаться не бесконечно.

P>Теоретически это круто, авто-повторы от имени сверх-тонких клиентов, но практически это лучше делать через гатевей, который понимает тот протокол, который поверх хттп. Тогда к нему можно прикрутить кучку дополнительных вещей.
Осталось понять, где мы его возьмём.

P>Прямое — идемпотентность нужно изначально закладывать в дизайн и тащить до тестов всех уровней, вне зависимости от того, описано чтото в спецификации хттп или нет.
Всё верно. Объём работы на серверной стороне никак не зависит от того, каким именно способом сделана идемпотентность. Более того — он будет таким же и для RPC-based подходов.
Потому что чудес не бывает. Если я изобрету способ делать идемпотентность без помощи прикладного программиста, то быстро заработаю многоденег

P>Да, мы не поддерживаем эту фичу. Собственно, быстро глянул, они предлагают для всех unsafe методов добавлять доп хидеры, один из которых и будет тем самым ключом идемпотентности.
P>Т.е. внагрузку к урл, будет еще один ключ. Разумная вещь.
Эта часть — она как у всех. Невозможно сделать POST идемпотентным без ключа идемпотентности.

P>В том то и дело, и это не зависит от транспорта. Потому имеет смысл втащить ключ идемпотентности в энвелоп в явном виде и сэкономить себе парочку седых волос. Поступай я иначе, была бы уже вся голова седая, а так у меня только клок другой в бороде седой
Что такое "в енвелоп"?
Давайте с другой стороны зайдём — у вас же в API авторизация есть? Указываете ли вы "bearerToken" в виде явного параметра у метода BL?

P>Я вот шота навскидку не могу представить, какой из сервисов-посредников поддерживает repeatable requests
Навскидку — никакой. К сожалению.
В итоге, авторы АПИ прикручивают авто-повторы к своим клиентским библиотекам.
Понятно, что в таком подходе можно выбирать любой вариант реализации идемпотентности: https://ably.com/topic/idempotency
Обратите внимание — с т.з. клиента никакого ключа идемпотентности у операции publish нету:

client = Ably::Rest::Client.new(key: api_key, idempotent_rest_publishing: true)
client.channels.get('example').publish([data: 'payload'])

S>>Хорошо, что мы от этого ушли в сторону REST.

P>Как по мне, так bff/edge-services, graphql и grpc пожрали и рест, и одату целиком. Скажем, на собесах меня перестали спрашивать по рест лет 5 назад. А про одату товарищи только знают, что этото чтото дотнетное, и ни единого вопроса не задают. Подумаешь, мелочовочка — запилить full-blown серверный процессин, фремворк поверх этого, кодогенератор и тд.
Ну, для меня REST — это прежде всего подход, а уже во вторую очередь — какой-то конкретный фреймворк и стандарт обмена данными.
Тот же graphQL не противоречит REST-у. C grpc сложнее — он эдакий кадавр, который может реализовать и RESTful, и RPC-style сервис.
Про bff/edge-services ничего не знаю.

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

P>>А что это меняет? Гарантии то всё равно слабые. Лучше подкинуть хидер prefer и получить результат в выхлопе post.
S>Речь не о том, что мы хотим сделать GET-после-PUT, а в некоторых мета-соглашениях об API.
S>Вот, к примеру, когда я вижу, что для создания нового экземпляра мне предлагается сделать POST на некий URL, у меня нет никакой информации о том, где я потом буду эту сущность запрашивать.
S>Ну да, обычно я могу увидеть список этих сущностей, выполнив GET на тот же URL. И тем не менее — не всегда понятно, чем именно адресуется конкретная сущность.
S>Никакие prefer тут не помогут.

POST /Orders вернет тебе хидер Location + опционально саму сущность, для которой, например, в одата, будет установлена метадата, типа @odata.editUrl или @odata.readUrl.
То есть, ажно два способа получить ровно то, что тебе надо.
Только при чем здесь идемпотентность?

S>У нас нет вот этой роскоши "поменять аннотацию и перекомпилировать гатевей", потому что мы вообще не контролируем вторую сторону.
S>Если мы вдруг решим перенести ключ идемпотентности из тела в хидер на стороне сервера, то это просто означает, что сколько-то тысяч клиентов упадут после деплоймента.

Упадут. Это я мальца погорячился.

S>А когда мы пишем клиента, у нас возникает вопрос "а как узнать, что и как себя ведёт". Про требования идемпотентности PUT мы знаем из публичных RFC, поэтому пишем наш код соответствующим образом.
S>Для POST мы должны глазами читать спецификацию на естественном языке. Которая очень редко бывает исчерпывающей, кстати.

Если нужны внятные гарантии повторяемости запроса, читать придется и там, и там. Другого варианта нет.

S>Обратите внимание, как замудрёно прикрутили идемпотентность POST к OData — там ещё и предусмотрен способ ограничить продолжительность обязанности сервера по поддержке идемпотентности.

Не только POST,а PUT, PATCH и еще DELETE. Т.е. речь о том, что встроеной в хттп идемпотентности мало на что хватает.

P>>Теоретически это круто, авто-повторы от имени сверх-тонких клиентов, но практически это лучше делать через гатевей, который понимает тот протокол, который поверх хттп. Тогда к нему можно прикрутить кучку дополнительных вещей.
S>Осталось понять, где мы его возьмём.

Напишем, разумеется. Его всё равно придется писать, в том или ином виде, если только не закладываться полностью на фичи клауда.

S>Потому что чудес не бывает. Если я изобрету способ делать идемпотентность без помощи прикладного программиста, то быстро заработаю многоденег



P>>В том то и дело, и это не зависит от транспорта. Потому имеет смысл втащить ключ идемпотентности в энвелоп в явном виде и сэкономить себе парочку седых волос. Поступай я иначе, была бы уже вся голова седая, а так у меня только клок другой в бороде седой
S>Что такое "в енвелоп"?
S>Давайте с другой стороны зайдём — у вас же в API авторизация есть? Указываете ли вы "bearerToken" в виде явного параметра у метода BL?

Нету. Её берет на себя гатевей, который физически reverse proxy. Реализация АПИ просто получает этот токен через context.authorization.

S>В итоге, авторы АПИ прикручивают авто-повторы к своим клиентским библиотекам.

А потому что автоповторы они разные, для какогото запроса хватит одного повтора, для какого то — серии, для других — долбить до посинения, пока 200 не вылезет. И это может повлечь изменение архитектуры, например, добавится message queue

S>Про bff/edge-services ничего не знаю.

Это способ логически вытащить часть фронтенда на сервер. Здесь нам вообще может хватить на всё одного POST, все остальные исключительно ради оптимизации под конкретные сценарии, и то не всегда.
Фактически, edge-service или bff это ручная реализация api гатевея, который умеет много всего — подклеивать авторизацию, трансформировать запрос, дергать кучу сервисов, повторять запросы и тд и тд. Буквально бизнес-логику такой сервис не выполняет, ну разве что валидацию парметров. Получается чтото среднее между http rest и graphql.
Со стороны страны все выглядит как вызов ровно одного метода типа documentPage.getFullData() и так вне зависимости от того, где делаем запрос — в браузере, в server side rendering, или изнутри другого сервиса.
Самое главное для этого бфф, это склейка клиента и сервера, что бы трансформировать апи можно было влёгкую и не надо было переписывать все тесты, если перетащил параметр из хидера в квери или наоборот.
Соответственно rest ушел в api фасад какого ресурса, который из внешней сети недоступен.

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

G>Что такое "операция"? Видимо речь о запросе, запрос это Метод+URL+Тело+Заголовки
Да, вот это вот всё.

G>Предложение оппонента сделать "идемпотентность" по полю тела или заголовка.
Нет. У оппонента предложение сделать именно "сильную" идемпотентность (не RFC-шную) по какому-либо ключу. Чтобы даже если есть другие (конкурирующие) операции между последовательными запросами, то операция не повторялась. Вряд ли мы говорим о том, что если вдруг сервер получает два разных запроса с одним и тем же idempotency key, то он должен выполнить новый запрос (это именно RFC-семантика). Ну и если уж быть совсем педантом, для идемпотентности на уровне RFC не нужно вообще никаких idempotency key. Сервер (инфраструктура) может просто запоминать последний запрос к ресурсу и просто выдавать сохраненный ответ, если запрос повторяется. Нет же, оппонент хочет какие-то idempotency key. Значит, мы все же о чем-то другом говорим. И вот обычно под idempotency key имеется в виду, что запрос может быть безопасно повторен при наличии конкурентных запросов.

M>>Далее. Похоже, в этой теме есть непонимание того, что такое идемпотентность. Прямо по определению (RFC 2616, 9.1.2) идемпотентность говорит, что req(req(state)) == req(state) (и как следствие req(req(req(...(req(state))...))) == req(state). Всё! В общем случае оно даже не гарантирует, что сломавшийся запрос можно безопасно повторять.
G>Как раз гарантирует. В случае неполучения ответа (пропадания связи) или ответа 500 можно повторять идемпотентный запрос пока не получишь другой ответ.
Гарантирует только при условии остутствия гонок (параллельных небезопасных запросов к тому же ресурсу). А если есть гонки, идемпотентность ничего не гарантирует.

G>Это к идемпотентности не имеет отношения. Это состояние гонки и с ним надо бороться другими методами.
Это имеет самое прямое отношение. В некоторых случаях методы борьбы с гонками настолько суровые, что идемпотентность нам больше не нужна. Допустим, мы решили, что все запросы от клиентов должны быть условные (conditional). С этого момента нам идемпотентность ничем не поможет. Потому что либо запрос проходит (и тогда мы знаем, что состояние не изменилось). Либо не проходит с диагностикой о том, что условие не выполняется и нужно разбираться с тем, какое же новое состояние имеет объект. Идемпотентность — один из способов обеспечения надежности, когда условия позволяют ее использовать.

M>>В самом HTTP для существующих глаголов есть два типа идемпотентности. Первый наблюдается у безопасных глаголов (GET/HEAD/OPTIONS). У них состояние ресурса не изменяется, т.е. req(state) == state. Второй тип наблюдается у глаголов PUT/DELETE. Для них выполняется семантика перезаписи.
G>Это называется SAFE и IDEMPOTENT
Первые — полностью согласен. Со вторыми сложнее. Класс (небезопасных) идемпотентных операций шире, чем представленный PUT и DELETE. Т.е. PUT и DELETE — идемпотентные, да. Но могут быть и идемпотентные глаголы с другой семантикой.

G>Суть разговора была в том, что оппонент предлагает использовать POST и <unique-op-id> в теле или заголовке
К сожалению, оппонент при этом не дает определения идемпотентности операции, которое он хочет достичь. И мне почему-то кажется, что здесь используется не RFC-шное определение.

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

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

С явными ключами идемпотентности нет проблем только в браузере. Если браузер был закрыт, запрос можно не повторять. А вот в API, к которому может обращаться сервер, явные ключи идемпотентности могут быть очень неудобны как раз потому, что их нужно генерировать и сохранять. Хотя бы на случай, когда данный инстанс будет остановлен и операцию докатывать будет уже другой экземпляр сервера.

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

M>Спасибо! Это очень существенный момент. Обычно для идемпотентного PUT таких приседаний не нужно. В хорошем API можно просто посылать желаемое (т.е. с точки зрения клиента — текущее) состояние и в случае конфликтов разбираться, где что-то пошло не так.
Я не очень понял, что вы имеете в виду под выделенным. Ну, можно просто игнорировать идемпотентность в интерактивных приложениях, оставляя пользователя наедине с request timed out.
Но если хочется хоть как-то пользоваться идемпотентностью, то нужна собственно логика повторов. Опять же, в интерактивном приложении мы можем выполнять шаг 1 не в персистентное хранилище, а просто держать всё в памяти.
Тогда идемпотентность будет ограничена временем жизни конкретного экземпляра приложения (а то и конкретного окна).

M>С явными ключами идемпотентности нет проблем только в браузере. Если браузер был закрыт, запрос можно не повторять. А вот в API, к которому может обращаться сервер, явные ключи идемпотентности могут быть очень неудобны как раз потому, что их нужно генерировать и сохранять. Хотя бы на случай, когда данный инстанс будет остановлен и операцию докатывать будет уже другой экземпляр сервера.

Совершенно верно. Сервер должен быть всегда готов к собственному сбою. По-другому никак нельзя.

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

M>>Обычно для идемпотентного PUT таких приседаний не нужно. В хорошем API можно просто посылать желаемое (т.е. с точки зрения клиента — текущее) состояние и в случае конфликтов разбираться, где что-то пошло не так.
S>Я не очень понял, что вы имеете в виду под выделенным.
У меня в основном серверные приложения. Типичный сценарий подразумевает, что в какой-то момент объект получает состояние "sending to provider" (без детализации но с разными таймаутами для повторов). В этом состоянии сервер посылает запрос. При успехе — обновляет состояние в базе. При ошибке — ничего не делает. Еще есть универсальный докат транзакций. Он выполняет "select * from entities where state == 'sending to provider'" и далее делает обычный PUT. Все это — относительно просто и универсально. Состояния явно соовтетствуют тому, что происходит на сервере.

Добавление ключей идемпотентности усложняет схему. В состояние добавляется новое поле "ключ идемпотентности". В ряде случаев это не очень сложно. В других — сложно. Например, может быть распределенная архитектура с микроядром (distributed microkernel architecture). Ядро обеспечивает общее изменение состояний. Интеграции с провайдерами обычно получают запрос от ядра, конвертируют его в формат провайдера и отправляют дальше. Во многих случаях эти интеграции вообще без состояния. Т.е. просто взяли запрос, преобразовали его (переместили поля, изменили названия и т.п.), отправили дальше. Потом разобрали/поменяли ответ и передали ядру. Добавление ключей идемпотентности запросто превращается в приключение. Нет никакой гарантии того, что у разных провайдеров будет одинаковый формат ключа. Поэтому приходится делать какую-то кастомизацию. Либо отдельный вызов для генерации таких ключей, либо генерация ключей идемпотентности в модуле интеграции. Во втором случае модуль получает свою отдельную базу данных. Это не всегда плохо, но и не всегда хорошо.

В общем, явные ключи идемпотентности добавляют лишние приседания (на сервере, да), которые не имеют естественного отображения в доменную модель. И добавляет совершенно синтетические атрибуты. А вот PUT (с состоянием "мы посылаем") — вполне естественное состояние в доменной модели. С браузером или клиентом проблем как раз гораздо меньше.

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

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

G>>Что такое "операция"? Видимо речь о запросе, запрос это Метод+URL+Тело+Заголовки
M>Да, вот это вот всё.

G>>Предложение оппонента сделать "идемпотентность" по полю тела или заголовка.
M>Нет. У оппонента предложение сделать именно "сильную" идемпотентность (не RFC-шную) по какому-либо ключу. Чтобы даже если есть другие (конкурирующие) операции между последовательными запросами, то операция не повторялась. Вряд ли мы говорим о том, что если вдруг сервер получает два разных запроса с одним и тем же idempotency key, то он должен выполнить новый запрос (это именно RFC-семантика). Ну и если уж быть совсем педантом, для идемпотентности на уровне RFC не нужно вообще никаких idempotency key. Сервер (инфраструктура) может просто запоминать последний запрос к ресурсу и просто выдавать сохраненный ответ, если запрос повторяется. Нет же, оппонент хочет какие-то idempotency key. Значит, мы все же о чем-то другом говорим. И вот обычно под idempotency key имеется в виду, что запрос может быть безопасно повторен при наличии конкурентных запросов.

Очень, очень верное замечание.
Есть ли ссылки на готовые материалы почитать по данной теме?
Я не припомню, чтобы я встречал где-то рассуждения о слабой/сильной идемпотентностях; хотя, очевидно, желанной является вторая.

Вот у нас есть три клиента — A, B, С,

1. A создаёт объект X.
2. B находит объект X, и модифицирует его (назовём новое состояние X').
3. С находит объект X' и удаляет его.

Теперь представим, что у всех троих нестабильная связь. Очевидно, что A должен иметь возможность повторять попытки создать X и после момента 2, и после момента 3.
При этом мы ожидаем, что он таки получит свой 201 — c его точки зрения, это первая успешная попытка создания.
Чего мы не ожидаем:
— что после 2 он получит 4хх — это бы выглядело так, как будто он сделал что-то нехорошее (пытается создать объект-дубликат)
— что после 2 он получит 200/201 и X' вернётся обратно в X (это бы нарушило ожидания B)
— что после 3 он восстановит X из мёртвых — это бы нарушило ожидания C
B, в свою очередь, должен иметь возможность продолжать повторять попытки изменения X.
По тем же причинам мы ожидаем, что даже после 3 он получит 200/202, а не 410 Gone и не восстановит X' из мёртвых.
При этом, очевидно, семантика RFC для этого совершенно недостаточна.

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

S>При этом, очевидно, семантика RFC для этого совершенно недостаточна.
Какой RFC имеется ввиду?
Все что необходимо для решения проблемы конкурентного обновления есть в https://httpwg.org/specs/rfc9110.html
Даже два механизма:
— заголовок ответа Last-Modified и изголовки запросов If-Modified-Since, If-Unmodifieed-Since
— заголовок ответа Etag и изголовки запросов If-Match, If-None-Match
Предполагается что в случае невыполнения условия сервер должен вернуть 412 Precondition Failed

S>Я не припомню, чтобы я встречал где-то рассуждения о слабой/сильной идемпотентностях; хотя, очевидно, желанной является вторая.
Потому что оно так никогда не называлось.

Идемпотентность по той же ссылке определяется вот так:

Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response

Нет никаких рассуждений о "сильной" или "слабой"

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

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

M>>Нет. У оппонента предложение сделать именно "сильную" идемпотентность (не RFC-шную) по какому-либо ключу. Чтобы даже если есть другие (конкурирующие) операции между последовательными запросами, то операция не повторялась. Вряд ли мы говорим о том, что если вдруг сервер получает два разных запроса с одним и тем же idempotency key, то он должен выполнить новый запрос (это именно RFC-семантика). Ну и если уж быть совсем педантом, для идемпотентности на уровне RFC не нужно вообще никаких idempotency key. Сервер (инфраструктура) может просто запоминать последний запрос к ресурсу и просто выдавать сохраненный ответ, если запрос повторяется. Нет же, оппонент хочет какие-то idempotency key. Значит, мы все же о чем-то другом говорим. И вот обычно под idempotency key имеется в виду, что запрос может быть безопасно повторен при наличии конкурентных запросов.

S>Очень, очень верное замечание.
S>Есть ли ссылки на готовые материалы почитать по данной теме?
S>Я не припомню, чтобы я встречал где-то рассуждения о слабой/сильной идемпотентностях; хотя, очевидно, желанной является вторая.

S>Вот у нас есть три клиента — A, B, С,

S>1. A создаёт объект X.
S>2. B находит объект X, и модифицирует его (назовём новое состояние X').
S>3. С находит объект X' и удаляет его.

У нас есть понятие идемпотентности метода, но не группы методов, связанных некой замысловатой семантикой. Т.е. мы можем говорить об идемпотентности PUT отдельно от идемпотентности DELETE, и у нас нет идемпотентности пары PUT+DELETE.
В этом наборе операций для A/B/C у нас ведь есть еще и GET, который вызвается в момент "находит"? Или это кондишнл PUT/DELETE? Если есть GET и параллельные операции создания, то уже одного PUT и GET достаточно что бы получить состояние гонки даже с одним клиентом. Методы PUT и GET должны вызываться взаимоисключающим образом и только так. Пока не получен ответ на PUT, все ответы GET будут скомпрометированы и наоборот. Это даже вне кондишнл и идемпотентности.
В ситуации с несколькими клиентами мы не в силах контролировать время отправки запроса и получения ответа на другом клиенте, т.е. все полученные с сервера ответы, даже без намеков на проблемы транспорта, оптимистические в лучшем случае.
Мы можем лишь придумать непротиворечивое поведение, решающее гонки в некоторых случаях, но это будет всего лишь наше решение, не имеющее ничего общего с идемпотентностью "группы методов со связанной семантикой".

S>Теперь представим, что у всех троих нестабильная связь. Очевидно, что A должен иметь возможность повторять попытки создать X и после момента 2, и после момента 3.
А дело же не только в связи. Пользователю приспичило в туалет, он захлопнул крышку ноута, ноут сделал кибернейт, а после туалета оказалось, что рабочее время вышло и запрос на удаление найденного в пятницу X вылетит лишь в понедельник. А может и не вылететь, если у ноута села батарейка.
S>При этом мы ожидаем, что он таки получит свой 201 — c его точки зрения, это первая успешная попытка создания.
S>Чего мы не ожидаем:
S>- что после 2 он получит 4хх — это бы выглядело так, как будто он сделал что-то нехорошее (пытается создать объект-дубликат)
S>- что после 2 он получит 200/201 и X' вернётся обратно в X (это бы нарушило ожидания B)
S>- что после 3 он восстановит X из мёртвых — это бы нарушило ожидания C
S>B, в свою очередь, должен иметь возможность продолжать повторять попытки изменения X.
S>По тем же причинам мы ожидаем, что даже после 3 он получит 200/202, а не 410 Gone и не восстановит X' из мёртвых.
S>При этом, очевидно, семантика RFC для этого совершенно недостаточна.
За данную задачу не скажу, не вижу, как ее решить правильно, требования не доконца ясны. Но в проекте корпоративной облачной файлопомойки, в котором я работаю, одноэтапное создание ресурса приводило к неизбежным гонкам, когда ресурс, созданный клиентом А, удалялся клиентом Б до момента получения А ответа о создании. Т.е. А продолжал его создавать при потере ответа сервера о создании, что было неприемлемо. Но в задаче A/B/C это вроде штатный сценарий.
Максимально стабильное решение получилось собрать с двухэтапным созданием ресурсов. Create POST-ом получает сессию с идентификатором нового ресурса, а CompleteCreate завершает создание ресурса на сервере, фактически публикуя созданный ранее скрытый ресурс. Состояние создания ресурса для клиента персистентно, он закончит его создание даже после ребута.

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

Тут нет задачи проявлять изобретательность в каждом конкретном случае. Можно же задачу обновления ресурса/коллекции ресурсов строить на общих подходах, например CASUpdate, где ключом будет версия/хэш/ETag ресурса. Аки в GIT. Уже упоминал где-то в начале темы.
Немного неизящно, т.к. мы не сможем ничего создать, не получив последнее состояние/версию ресурса. Не сгодится для высоконагруженных систем без троттлинга со стороны клиентов. А в целлом будет как-то работать.

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

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

S>>При этом, очевидно, семантика RFC для этого совершенно недостаточна.
G>Какой RFC имеется ввиду?
2616 и 9110.

G>Все что необходимо для решения проблемы конкурентного обновления есть в https://httpwg.org/specs/rfc9110.html
G>Даже два механизма:
G>- заголовок ответа Last-Modified и изголовки запросов If-Modified-Since, If-Unmodifieed-Since
G>- заголовок ответа Etag и изголовки запросов If-Match, If-None-Match
G>Предполагается что в случае невыполнения условия сервер должен вернуть 412 Precondition Failed
Это нарушает ожидания от "сильной идемпотентности". И даже с этими хидерами у нас нет никакой гарантии соблюдения идемпотентности в случае взаимодействия с сервером нескольких клиентов.
Попробуйте "починить" приведённый мной пример при помощи добавления этих заголовков в запросы и ответы.
Парочку из аномалий вы предотвратите, но не все.

S>>Я не припомню, чтобы я встречал где-то рассуждения о слабой/сильной идемпотентностях; хотя, очевидно, желанной является вторая.
G>Потому что оно так никогда не называлось.

G>Идемпотентность по той же ссылке определяется вот так:
G>

G>Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response

G>Нет никаких рассуждений о "сильной" или "слабой"
В том-то и дело, что в спеке неявно подразумевается, что клиент — единственный, кто взаимодействует с заданным ресурсом на сервере.

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

S>У нас есть понятие идемпотентности метода, но не группы методов, связанных некой замысловатой семантикой. Т.е. мы можем говорить об идемпотентности PUT отдельно от идемпотентности DELETE, и у нас нет идемпотентности пары PUT+DELETE.
Нет никакой пары. Каждый клиент "видит" только себя и сервер, и пытается реализовать наилучшую, на его взгляд, стратегию работы.

S>В этом наборе операций для A/B/C у нас ведь есть еще и GET, который вызвается в момент "находит"?
Да, конечно. Клиенты B и C используют GET (причём, скорее всего, на уровень выше в иерархии — типа "дай мне список X подходящих под условие отбора")ю

S>Или это кондишнл PUT/DELETE? Если есть GET и параллельные операции создания, то уже одного PUT и GET достаточно что бы получить состояние гонки даже с одним клиентом. Методы PUT и GET должны вызываться взаимоисключающим образом и только так. Пока не получен ответ на PUT, все ответы GET будут скомпрометированы и наоборот. Это даже вне кондишнл и идемпотентности.
С чего бы это вдруг? С точки зрения сервера, первый же PUT был успешным. У него нет никаких причин полагать, что A не получил ответ. Стало быть, он считает X вполне себе валидным ресурсом, который доступен для произвольных манипуляций B и C.
S>В ситуации с несколькими клиентами мы не в силах контролировать время отправки запроса и получения ответа на другом клиенте, т.е. все полученные с сервера ответы, даже без намеков на проблемы транспорта, оптимистические в лучшем случае.
Это всего лишь влияет на то, что B получает в своей выдаче. Относительность времени между A и B означает, что B мог не увидеть X, если сервер трактует его GET как прибывший раньше PUT.
Но если B "нашёл" X, то сервер уже не может "притвориться", что X нету.
Ок, опытный B, конечно же, примет меры для предотвращения lost update — в частности, в своём PUT он подложит If-Match, чтобы нечаянно не сломать потенциальных конкурентов, которые могли успеть сделать из X X" в промежутке между GET и PUT. Но смотрите, в чём беда — при повторах своего update B рискует дождаться момента после 3:DELETE, пришедшего от C. Что делать серверу? Формально, If-Match требует отдать 4хх, т.к. ожидаемого X там больше нет.
Если это и будет первым успешно доставленным респонсом на запросы B, то он будет введён в заблуждение. B будет считать, что он так и не успел обновить X перед удалением. А это не так, и это может быть важно из-за семантики приложения.

S>>Теперь представим, что у всех троих нестабильная связь. Очевидно, что A должен иметь возможность повторять попытки создать X и после момента 2, и после момента 3.
S>А дело же не только в связи. Пользователю приспичило в туалет, он захлопнул крышку ноута, ноут сделал кибернейт, а после туалета оказалось, что рабочее время вышло и запрос на удаление найденного в пятницу X вылетит лишь в понедельник. А может и не вылететь, если у ноута села батарейка.
Всё верно. Но если запрос на удаление таки поедет в понедельник, то никакого противоречия не будет — что бы там ни ответил сервер, это будет корректно. Например, вмешался D, который изменил Х' на X", и теперь его нельзя удалять без проверки. Отлично. Но если удаление таки прошло в пятницу, а в понедельник сервер делает вид, что ничего такого не было — это уже ай-яй-яй.

S>За данную задачу не скажу, не вижу, как ее решить правильно, требования не доконца ясны. Но в проекте корпоративной облачной файлопомойки, в котором я работаю, одноэтапное создание ресурса приводило к неизбежным гонкам, когда ресурс, созданный клиентом А, удалялся клиентом Б до момента получения А ответа о создании. Т.е. А продолжал его создавать при потере ответа сервера о создании, что было неприемлемо. Но в задаче A/B/C это вроде штатный сценарий.
Нет, это как раз вырожденный вариант, в котором участвуют A и C. В хорошей реализации, независимо от проблем связи, ресурс X должен на сервере проходить жизненный цикл "появился-умер" однократно.
А не так, что он будет "мерцать", пока A и C борются с недоставкой ответов, и результат зависит только от того, у кого их них первым восстановится двусторонняя связь.

S>Максимально стабильное решение получилось собрать с двухэтапным созданием ресурсов. Create POST-ом получает сессию с идентификатором нового ресурса, а CompleteCreate завершает создание ресурса на сервере, фактически публикуя созданный ранее скрытый ресурс. Состояние создания ресурса для клиента персистентно, он закончит его создание даже после ребута.
Звучит как реализация той самой "сильной" идемпотентности вручную.

S>Своим примером я хочу показать, что задача примерно та же, отличается небольшой деталью, но рабочего решения за счет идемпотенетности или кондишнл не видно.
Ну вот есть подозрение, что спека на repeatable requests OData позволяет решить эту проблему. Надо бы поковырять это повнимательнее.

S>Немного неизящно, т.к. мы не сможем ничего создать, не получив последнее состояние/версию ресурса. Не сгодится для высоконагруженных систем без троттлинга со стороны клиентов. А в целлом будет как-то работать.
Да, тут надо повнимательнее посмотреть на вопрос с таймстампами. Если удастся их верно назначить на стороне сервера, то будет работать корректное упорядочивание запросов, и можно будет всем раздавать повторяемые ответы.

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

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

S>>У нас есть понятие идемпотентности метода, но не группы методов, связанных некой замысловатой семантикой. Т.е. мы можем говорить об идемпотентности PUT отдельно от идемпотентности DELETE, и у нас нет идемпотентности пары PUT+DELETE.
S>Нет никакой пары. Каждый клиент "видит" только себя и сервер, и пытается реализовать наилучшую, на его взгляд, стратегию работы.
Я о паре/совокупности методов, а не про пару клиентов.

S>>Или это кондишнл PUT/DELETE? Если есть GET и параллельные операции создания, то уже одного PUT и GET достаточно что бы получить состояние гонки даже с одним клиентом. Методы PUT и GET должны вызываться взаимоисключающим образом и только так. Пока не получен ответ на PUT, все ответы GET будут скомпрометированы и наоборот. Это даже вне кондишнл и идемпотентности.
S>С чего бы это вдруг? С точки зрения сервера, первый же PUT был успешным. У него нет никаких причин полагать, что A не получил ответ. Стало быть, он считает X вполне себе валидным ресурсом, который доступен для произвольных манипуляций B и C.
С точки зрения клиента. Если он отправил GET и PUT, не дождавшись ответа GET, или наоборот, то клиент не сможет узнать по ответу GET, мог ли быть выполнен отправленный им PUT и чей-то DELETE, если в ответе GET нет X.

S>>В ситуации с несколькими клиентами мы не в силах контролировать время отправки запроса и получения ответа на другом клиенте, т.е. все полученные с сервера ответы, даже без намеков на проблемы транспорта, оптимистические в лучшем случае.
S>Это всего лишь влияет на то, что B получает в своей выдаче. Относительность времени между A и B означает, что B мог не увидеть X, если сервер трактует его GET как прибывший раньше PUT.
Исхожу из того, что сервер вообще не знает, кто когда отправил запрос, отвечает моментально в момент получения запроса и не думает о том, кому что показать, показывая свое текущее состояние. Пусть, например, он хранит свое состояние в критической секции, или делает вид что происходит именно это.
S>Но если B "нашёл" X, то сервер уже не может "притвориться", что X нету.
Может, если допускается B2, который уже поменял X->X2
S>Ок, опытный B, конечно же, примет меры для предотвращения lost update — в частности, в своём PUT он подложит If-Match, чтобы нечаянно не сломать потенциальных конкурентов, которые могли успеть сделать из X X" в промежутке между GET и PUT. Но смотрите, в чём беда — при повторах своего update B рискует дождаться момента после 3:DELETE, пришедшего от C. Что делать серверу? Формально, If-Match требует отдать 4хх, т.к. ожидаемого X там больше нет.
S>Если это и будет первым успешно доставленным респонсом на запросы B, то он будет введён в заблуждение. B будет считать, что он так и не успел обновить X перед удалением. А это не так, и это может быть важно из-за семантики приложения.
Понимаю. И идемпотентность не снимает проблем гонок с разделяемым состоянием. Она не для этого. Это проблема разработчика — обеспечить корректную работу в соответствии с семантикой приложения, не забыв об идемпотентности, которая обеспечит ему возможность повтора вызовов и только лишь.

S>Всё верно. Но если запрос на удаление таки поедет в понедельник, то никакого противоречия не будет — что бы там ни ответил сервер, это будет корректно. Например, вмешался D, который изменил Х' на X", и теперь его нельзя удалять без проверки. Отлично. Но если удаление таки прошло в пятницу, а в понедельник сервер делает вид, что ничего такого не было — это уже ай-яй-яй.
Я хотел продемонстрировать (для других, уверен, что мы с вами понимаем), что проблема не в одной лишь связи, которая может быть сколь угодно надежна. Уже были примеры с метро. А это в плюс пример с офисом, езернетом и резервным питанием всего, что можно.
Но да, не там сделал акцент. Пусть ситуация будет такая, что запрос отправлен, а ответ пришел уже после ухода в кибернейт. Приложение просыпается в понедельник — ответа нет. В контексте исполняющегося потока кода для приложения довольно сложно определить, что предыдущая строчка с вызовом метода выполнялась на прошлой неделе, а текущая — уже на новой неделе. Ответа сервера нет и не будет.

S>>За данную задачу не скажу, не вижу, как ее решить правильно, требования не доконца ясны. Но в проекте корпоративной облачной файлопомойки, в котором я работаю, одноэтапное создание ресурса приводило к неизбежным гонкам, когда ресурс, созданный клиентом А, удалялся клиентом Б до момента получения А ответа о создании. Т.е. А продолжал его создавать при потере ответа сервера о создании, что было неприемлемо. Но в задаче A/B/C это вроде штатный сценарий.
S>Нет, это как раз вырожденный вариант, в котором участвуют A и C. В хорошей реализации, независимо от проблем связи, ресурс X должен на сервере проходить жизненный цикл "появился-умер" однократно.
S>А не так, что он будет "мерцать", пока A и C борются с недоставкой ответов, и результат зависит только от того, у кого их них первым восстановится двусторонняя связь.
Это зависит от задачи. Вполне допускаю такую задачу, где ресрус именно должен мерцать. Причем, даже без GET. Один лупит PUT X, другой — DELETE X в цикле. Например, синтетическая задача по замеру среднего времени жизни ресурса в таких условиях при разном количестве создающих и удаляющих клиентов.
Не настаиваю на рассмотрении именно такой задачи.

S>>Максимально стабильное решение получилось собрать с двухэтапным созданием ресурсов. Create POST-ом получает сессию с идентификатором нового ресурса, а CompleteCreate завершает создание ресурса на сервере, фактически публикуя созданный ранее скрытый ресурс. Состояние создания ресурса для клиента персистентно, он закончит его создание даже после ребута.
S>Звучит как реализация той самой "сильной" идемпотентности вручную.
Возможно, так и есть, но я не думал об этом в терминах "сильной" идемпотентности. обычная книжная идемпотентность в рамках этого решения решает лишь свою маленькую задачку.

S>>Своим примером я хочу показать, что задача примерно та же, отличается небольшой деталью, но рабочего решения за счет идемпотенетности или кондишнл не видно.
S>Ну вот есть подозрение, что спека на repeatable requests OData позволяет решить эту проблему. Надо бы поковырять это повнимательнее.
На сколько я понял — нет, не решает. Там предлагают использовать заголовки для того, что бы отличать один PUT X со своими повторами от второго, логически с первым не связанным PUT X со своими повторами, причем, помечать для сервера так же первую попытку вызова от повторных.
так повторный PATCH с добавлением элемента коллекции на сервере можно будет отличить от намеренного добавления дубля ранее добавленного элемента.

S>>Немного неизящно, т.к. мы не сможем ничего создать, не получив последнее состояние/версию ресурса. Не сгодится для высоконагруженных систем без троттлинга со стороны клиентов. А в целлом будет как-то работать.
S>Да, тут надо повнимательнее посмотреть на вопрос с таймстампами. Если удастся их верно назначить на стороне сервера, то будет работать корректное упорядочивание запросов, и можно будет всем раздавать повторяемые ответы.
Чистые таймстампы будут препятствовать масштабированию сервера. Та еще мина.

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

S>Это всего лишь влияет на то, что B получает в своей выдаче. Относительность времени между A и B означает, что B мог не увидеть X, если сервер трактует его GET как прибывший раньше PUT.
Как я понимаю, идемпотентность позоволяет добавить между клиентом и сервером кеширующий прокси. Как мне кажется, это упрощает понимание сценариев, если предположить, что есть такой прокси, который "абсолютно надёжен" и кеширует все ответы сервера в соответствии с rfc (по урлу как ключу, по глаголам, с обработкой соответсвующих заголовков типа if-match и т.п.). В таком случае сервер видит запрос ровно один раз и даёт ровно один ответ. Клиент, если не смог получить ответ в первый раз, всегда получит его от прокси, в том же виде.

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

Важно не наличие прокси, а сама возможность восстановить когерентность состояния после сбоя.
Вот у вас есть микросервис Х, который выставляет наружу некоторую операцию A.
Для выполнения этой операции нужно выполнить две операции — A1 и A2, в микросервисах Y и Z.
Для конкретики: А1 — это списание денег, А2 — резервирование авиабилета.
Z ничего не знает про деньги; его работа — чисто резервирование билетов от имени агента.
Y ничего не знает про билеты; его работа — чисто обработка платежей.
Теперь учтём, к примеру, то, что X может внезапно упасть в любой момент:
— до первого обращения к Y
— после обращения к Y, но до того, как ответ от Y сохранён в локальную базу
— после обращения к Y, но перед обращением к Z
— после обращения к Z, но до того, как ответ от Z сохранён в локальную базу.

Плюс к этому, даже если сам X вполне себе функционален, возможен сбой коммуникации между ним и Y/Z. Возможен сбой самих Y и Z — причём в произвольные моменты:
— до получения запроса
— после получения запроса, но до внесения изменений в локальную базу
— после внесения изменений в базу, но до отправки ответа X

Единственный способ избежать безумия и дорогостоящих рукопашных процедур восстановления когерентности — это идемпотентность.
X полагается на то, что у него есть безопасный способ повтора операции, если он "не расслышал" или "забыл" ответ на предыдущий запрос.
Тогда у него есть штатный способ, не зависящий от ручного вмешательства инженеров, довести свою работу "оформление заказа на авиабилет" до конца — успешного там или неуспешного.

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

S>Вот у нас есть три клиента — A, B, С,

S>1. A создаёт объект X.
S>2. B находит объект X, и модифицирует его (назовём новое состояние X').
S>3. С находит объект X' и удаляет его.

S>Теперь представим, что у всех троих нестабильная связь. Очевидно, что A должен иметь возможность повторять попытки создать X и после момента 2, и после момента 3.
S>При этом мы ожидаем, что он таки получит свой 201 — c его точки зрения, это первая успешная попытка создания.
S>Чего мы не ожидаем:
S>- что после 2 он получит 4хх — это бы выглядело так, как будто он сделал что-то нехорошее (пытается создать объект-дубликат)

Не вижу в этом проблем. Любая достаточно большая распределённая система постоянно работает с ошибками. Это её нормальное состояние. Любой компонент получает ошибки. Везде есть какие-то баги. Никто не ставит алярмы на единственный HTTP 400. Алярмы ставят, когда ошибок становится больше ожидаемого процента.

То бишь в описанной ситуации A при повторе получает ошибку 400, логгирует её и успокаивается. При этом если для него важно как-то проверять после создания, есть ли объект — он должен сделать GET или подобный запрос и дальше уже работать исходя из этого.

B и C так же получают ошибку и так же примерно с ней работают.

Учитывая, что вероятность этой ошибки невелика, проблем это не вызывает. Главное, чтобы каждый компонент работал устойчиво при наличии этих ошибок.

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

S>В том-то и дело, что в спеке неявно подразумевается, что клиент — единственный, кто взаимодействует с заданным ресурсом на сервере.
Я так не думаю. Неглупые люди писали спеку, в первым автором вообще-то филдинг числится.
Если в спеке не закладывалась идея "сильной идемпотентности", то есть с сохранением порядка запросов, то, видимо, или другие способы обеспечения есть, или "овчинка не стоит выделки".


G>>Все что необходимо для решения проблемы конкурентного обновления есть в https://httpwg.org/specs/rfc9110.html
G>>Даже два механизма:
G>>- заголовок ответа Last-Modified и изголовки запросов If-Modified-Since, If-Unmodifieed-Since
G>>- заголовок ответа Etag и изголовки запросов If-Match, If-None-Match
G>>Предполагается что в случае невыполнения условия сервер должен вернуть 412 Precondition Failed
S>Это нарушает ожидания от "сильной идемпотентности". И даже с этими хидерами у нас нет никакой гарантии соблюдения идемпотентности в случае взаимодействия с сервером нескольких клиентов.
S>Попробуйте "починить" приведённый мной пример при помощи добавления этих заголовков в запросы и ответы.
S>Парочку из аномалий вы предотвратите, но не все.

По факту остается только одна проблема, если повторно выполнить PUT с If-None-Match: *, то будет 412 если предыдущая попытка была успешна, но мы не получили ответ.
С другой стороны в этом запросе 412 однозначно трактуется как "запись с этим ключом уже существует" и приложение может продолжать выполнение опираясь на это факт.

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

S>Для конкретики: А1 — это списание денег, А2 — резервирование авиабилета.
S>Z ничего не знает про деньги; его работа — чисто резервирование билетов от имени агента.
S>Y ничего не знает про билеты; его работа — чисто обработка платежей.

Тут мы попадаем на CAP теорему.
Это означает что нам нужно требовать отсутствие разделения, то есть утверждать, что пропадания связи с А1 и А2 или будут совсем отсутствовать, или будут заранее ограничены. Тогда мы можем сделать свой координатор, который будет принимать одним запросом данные билетах и платежах, а сам будет организовывать повторы столько раз сколько необходимо, даже с учетом перезагрузки самого координатора.

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

S>Важно не наличие прокси, а сама возможность восстановить когерентность состояния после сбоя.
Для меня прокси как умственный констркут, позволяющий мыслить как операции работают, упрощают понимание сути.
Т.е. вместо того, чтобы мучиться рассуждениями как должен себя вести сервер при получении дубликатов — просто можно считать, что до сервера дубликаты не доходят, а этим занимается прокси. Иными словами, вместо одного сверхумного компонента, рассматриваем два простых — тупой сервер который умеет обрабатывать один запрос без повторов и кеш который тупо возвращает то что видел.

S>Вот у вас есть микросервис Х, который выставляет наружу некоторую операцию A.
S>Для выполнения этой операции нужно выполнить две операции — A1 и A2, в микросервисах Y и Z.
По-моему ты ожидаешь от идемпотентности больше, чем положено. Идемпотентность про одну операцию, а не про их взаимодействие. (вспомни формулу f ∘ f = f — там нет никаких A,Y,Z, ровно одна функция).

S>Для конкретики: А1 — это списание денег, А2 — резервирование авиабилета.
S>Z ничего не знает про деньги; его работа — чисто резервирование билетов от имени агента.
S>Y ничего не знает про билеты; его работа — чисто обработка платежей.
А это всё разруливается бизнес-логикой и универсального решения нет. Ну и CAP подлянки подстраивает.
Например, типично делают временную блокировку билета (скажем на 15 минут) в течение которой должна пройти успешно оплата. После этого уже резервирование билета.
Притом, в случае технической проблемы (всё упало, и после оплаты не удалось уложиться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.

Здравствуйте, vsb, Вы писали:
vsb>Не вижу в этом проблем.
А зря.
vsb>Любая достаточно большая распределённая система постоянно работает с ошибками. Это её нормальное состояние. Любой компонент получает ошибки. Везде есть какие-то баги. Никто не ставит алярмы на единственный HTTP 400. Алярмы ставят, когда ошибок становится больше ожидаемого процента.
Дело не в алярме, а в восстановлении после сбоя. Получить 200 ок, когда на самом деле API Call упал — ничуть не хуже, чем получить 4хх, когда он на самом деле сработал.

vsb>То бишь в описанной ситуации A при повторе получает ошибку 400, логгирует её и успокаивается. При этом если для него важно как-то проверять после создания, есть ли объект — он должен сделать GET или подобный запрос и дальше уже работать исходя из этого.
Вот наш клиент позвал метод "перевести деньги", получил 4хх. Ок, у нас есть автоматизированная схема "попробовать следующий метод платежа".
Попробовал — получил 200, пометил у себя "всё ок, я оплатил заказ". В итоге продавцу деньги ушли дважды, и поймаем мы это только через месяцок, когда будем сверять баланс счёта.

vsb>B и C так же получают ошибку и так же примерно с ней работают.
Неа.

vsb>Учитывая, что вероятность этой ошибки невелика, проблем это не вызывает. Главное, чтобы каждый компонент работал устойчиво при наличии этих ошибок.
Вызывает Невозможно обеспечить "устойчивую работу", если для этого не предложено средств.

Здравствуйте, ·, Вы писали:
·>Т.е. вместо того, чтобы мучиться рассуждениями как должен себя вести сервер при получении дубликатов — просто можно считать, что до сервера дубликаты не доходят, а этим занимается прокси. Иными словами, вместо одного сверхумного компонента, рассматриваем два простых — тупой сервер который умеет обрабатывать один запрос без повторов и кеш который тупо возвращает то что видел.
Можно, но это никак не поможет рассуждать о корректности. В описанном сценарии прокси между A/B/C и сервисах ничего не изменят — по-прежнему состояние сервера будет разрушено, хотя каждый из клиентов всё делал безупречно.

·>По-моему ты ожидаешь от идемпотентности больше, чем положено. Идемпотентность про одну операцию, а не про их взаимодействие. (вспомни формулу f ∘ f = f — там нет никаких A,Y,Z, ровно одна функция).
Я иду с другой стороны. У меня нет задачи "о, прикольная штука эта ваша идемпотентность, к чему бы полезному её пристроить". У меня задача — ровно наоборот: спроектировать и реализовать API, который позволяет написать к нему клиентов, которые смогут корректно работать при наличии сбоев.

·>А это всё разруливается бизнес-логикой и универсального решения нет.
Если мы придумаем решение для этой конкретной бизнес-логики, то оно легко станет универсальным.
·>Ну и CAP подлянки подстраивает.
Нет, CAP тут ни при чём.
·>Например, типично делают временную блокировку билета (скажем на 15 минут) в течение которой должна пройти успешно оплата. После этого уже резервирование билета.
Это вообще не решение. Вот у нас оплата успешно прошла, но клиент об этом не узнал. Дальше что?
·>Притом, в случае технической проблемы (всё упало, и после оплаты не удалось уложиться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.
Ну вот я и хочу избавиться от ручной утряски — это очень дорогостоящая процедура.

Здравствуйте, gandjustas, Вы писали:
G>Тут мы попадаем на CAP теорему.
Не вижу её применимости.
G>Это означает что нам нужно требовать отсутствие разделения, то есть утверждать, что пропадания связи с А1 и А2 или будут совсем отсутствовать, или будут заранее ограничены. Тогда мы можем сделать свой координатор, который будет принимать одним запросом данные билетах и платежах, а сам будет организовывать повторы столько раз сколько необходимо, даже с учетом перезагрузки самого координатора.
Нет конечно. CAP — очень убогая штука, она оперирует слишком ограниченными определениями.
В нашем случае достаточно понимать, что по мере повторных выполнений идемпотентных запросов вероятность продолжить некогерентность падает экспоненциально быстро.
Грубо говоря, 90% запросов будут обработаны с одного раза.
9% потребуют одного повтора.
<1 потребуют трёх повторов.

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

S>·>Т.е. вместо того, чтобы мучиться рассуждениями как должен себя вести сервер при получении дубликатов — просто можно считать, что до сервера дубликаты не доходят, а этим занимается прокси. Иными словами, вместо одного сверхумного компонента, рассматриваем два простых — тупой сервер который умеет обрабатывать один запрос без повторов и кеш который тупо возвращает то что видел.
S>Можно, но это никак не поможет рассуждать о корректности. В описанном сценарии прокси между A/B/C и сервисах ничего не изменят — по-прежнему состояние сервера будет разрушено, хотя каждый из клиентов всё делал безупречно.
Не очень ясно причём тут идемпотентность тогда. Идемпотентность никак не помогает рассуждать о корректности взаимодействия между множеством систем, только между двумя. Именно между двумя системами происходит State Transfer.

S>·>По-моему ты ожидаешь от идемпотентности больше, чем положено. Идемпотентность про одну операцию, а не про их взаимодействие. (вспомни формулу f ∘ f = f — там нет никаких A,Y,Z, ровно одна функция).
S>Я иду с другой стороны. У меня нет задачи "о, прикольная штука эта ваша идемпотентность, к чему бы полезному её пристроить". У меня задача — ровно наоборот: спроектировать и реализовать API, который позволяет написать к нему клиентов, которые смогут корректно работать при наличии сбоев.
Так это уже CAP.

S>·>А это всё разруливается бизнес-логикой и универсального решения нет.
S>Если мы придумаем решение для этой конкретной бизнес-логики, то оно легко станет универсальным.
S>·>Ну и CAP подлянки подстраивает.
S>Нет, CAP тут ни при чём.
Именно причём. У тебя происходит Partitioning (между клиентом и сервером произошел разрыв связи) и бизнес должен решить, чем жертвовать C или A.

S>·>Например, типично делают временную блокировку билета (скажем на 15 минут) в течение которой должна пройти успешно оплата. После этого уже резервирование билета.
S>Это вообще не решение. Вот у нас оплата успешно прошла, но клиент об этом не узнал. Дальше что?
Оплата прошла, билет куплен успешно. Если у клиент об этом не узнал (мобильник выпал из рук и разбился), то это забота клиента найти способ связаться и узнать о результате.

S>·>Притом, в случае технической проблемы (всё упало, и после оплаты не удалось уложиться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.
S>Ну вот я и хочу избавиться от ручной утряски — это очень дорогостоящая процедура.
А есть варианты? И, главное, причём тут идемпотентность?

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

·>Не очень ясно причём тут идемпотентность тогда. Идемпотентность никак не помогает рассуждать о корректности взаимодействия между множеством систем, только между двумя. Именно между двумя системами происходит State Transfer.
Ну так у нас взаимодействие всегда происходит между двумя системами. Я же вроде очень подробно пример расписал. Непонятно, что вам непонятно

·>Так это уже CAP.
Нет. CAP — это некий удобный акроним, на который можно списать всё, что угодно. Утекли деньги со счёта — "это CAP виновата ". Нет, это так не работает.


·>Именно причём. У тебя происходит Partitioning (между клиентом и сервером произошел разрыв связи) и бизнес должен решить, чем жертвовать C или A.
Ок, я выбираю пожертвовать A (хотя это опять ложная дилемма — A не является бинарной величиной). Верните мне мою C.

·>Оплата прошла, билет куплен успешно. Если у клиент об этом не узнал (мобильник выпал из рук и разбился), то это забота клиента найти способ связаться и узнать о результате.
Не мобильник выпал и разбился, а VM была перезапущена в рамках стандартного failover. Клиент — это серверный процесс. Как именно вы предлагаетее ему "связаться и узнать о результатах"?

иться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.
S>>Ну вот я и хочу избавиться от ручной утряски — это очень дорогостоящая процедура.
·>А есть варианты? И, главное, причём тут идемпотентность?
Конечно есть. Вариант — обеспечить идемпотентность запросов. Даже в случае возможных конкурирующих запросов от других клиентов.

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

S>В нашем случае достаточно понимать, что по мере повторных выполнений идемпотентных запросов вероятность продолжить некогерентность падает экспоненциально быстро.
S>Грубо говоря, 90% запросов будут обработаны с одного раза.
S>9% потребуют одного повтора.
S><1 потребуют трёх повторов.
В описано сценарии надо еще и отказ обрабатывать:
1) Если бронь не прошла, то надо откатить оплату
2) Если оплата не прошла, то надо откатить бронь
3) Тот кто отправляет запросы может перезагрузиться в любой момент и при этом должно отработать все корректно
И при этом на каждом шаге еще и может возникнуть необходимость повторов.

В общем это очень сложная задача. И она очень похожа на "задачу о двух генералах".

Поэтому в реальности бронирование билетов происходит таким образом:
1) После выбора билетов клиентом сразу отправляется предварительная бронь, она держится от 5 от 30 минут
2) За этим 5-30 минут клиент должен выбрать опции и способ оплаты. В это время никто другой не может взаимодействовать с забронированными местами.
3) После оплаты отправляется подтверждение сервису бронирования. Причем сразу по двум путям — одно от клиента с кодом оплаты, второе отправляет сам платежный сервер в систему бронирования. Если получено подтверждение интерактивным путем, то клиент сразу получает билет, если фоновым, то отправляется на почту (обычно происходит оба варианта).
4) Если подтверждение до сервера бронирования так и не дошло за 5-30 минут, то то сервер пытается отменить оплаты по код бронирования.

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

Я думаю те, кто писали спеку 9110 прекрасно понимали сложность систем с повторами и порядком доставки сообщений, поэтому не включали в понятие идемпотентности сохранение порядка запросов, ибо во многих случаях это сложная, но мало чего дает клиенту.

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


S>·>Так это уже CAP.
S>Нет. CAP — это некий удобный акроним, на который можно списать всё, что угодно. Утекли деньги со счёта — "это CAP виновата ". Нет, это так не работает.
CAP это проблема, которую должен решать программист. При наличии признаков CAP надо понимать что при потере связи система будет терять согласованность или доступность.
И надо будет что-то делать, чтобы не терять.
Или увеличивать надежность сетевых соединений, уменьшая время потери доступности, или вносить в систему механизм восстановления согласованности, если часть сообщений потерялась.
В простых случаях механизм восстановления согласованности может быть тупым — повторять запросы, пока что-нибудь не вернет. Но часто оказывается сложнее, примерно как при покупке билетов, который я описал выше.

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

S>·>Не очень ясно причём тут идемпотентность тогда. Идемпотентность никак не помогает рассуждать о корректности взаимодействия между множеством систем, только между двумя. Именно между двумя системами происходит State Transfer.
S>Ну так у нас взаимодействие всегда происходит между двумя системами. Я же вроде очень подробно пример расписал. Непонятно, что вам непонятно
Да. Но ты хочешь добиться каких-то гарантий между 2+ систем. Partitioning мешается.

S>·>Так это уже CAP.
S>Нет. CAP — это некий удобный акроним, на который можно списать всё, что угодно. Утекли деньги со счёта — "это CAP виновата ". Нет, это так не работает.
Не совсем. CAP диктует какие сценарии возможны. А это уже дело BA определить поведение адекватное с т.з. бизнеса в таких сценариях.

S>·>Именно причём. У тебя происходит Partitioning (между клиентом и сервером произошел разрыв связи) и бизнес должен решить, чем жертвовать C или A.
S>Ок, я выбираю пожертвовать A (хотя это опять ложная дилемма — A не является бинарной величиной). Верните мне мою C.
Ну в рассамтриваемом примере это означает, что самолёт никуда не полетит (no Availability) пока каждый из заказов не подвердится/отклонится каждым из клиентов.

S>·>Оплата прошла, билет куплен успешно. Если у клиент об этом не узнал (мобильник выпал из рук и разбился), то это забота клиента найти способ связаться и узнать о результате.
S>Не мобильник выпал и разбился, а VM была перезапущена в рамках стандартного failover. Клиент — это серверный процесс.
Да без разницы, человек это или vm. failover может перезапустить процесс, но что-то опять может пойти не так. Место на диске закончилось, например, и процесс застрял. А админы спят, диск почистить некому, самолёт готовится к вылету. Шо делать?

S>Как именно вы предлагаетее ему "связаться и узнать о результатах"?
Или я вопрос не понял?..

S>иться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.
S>>>Ну вот я и хочу избавиться от ручной утряски — это очень дорогостоящая процедура.
S>·>А есть варианты? И, главное, причём тут идемпотентность?
S>Конечно есть. Вариант — обеспечить идемпотентность запросов. Даже в случае возможных конкурирующих запросов от других клиентов.
Как это поможет в случае "клиент об этом не узнал"?