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

M>>Если запрос применим в состояниях s1 и s2, то состояние после выполнения запроса одно и то же: req(s1) == req(s2). На практике для безопасного повторения запросов в системах со многими акторами хотелось бы больших гарантий.
НС>В распределенных системах это вряд ли реализуемо, так как упирается в САР-теорему. Максимум можно такое обеспечить для асинхронных операций, и то это будет та еще эквилибристика.
А что сложного? Если у нас REST, то CAP нам не мешает. Мы уже более-менее согласились на eventual consistency. Поэтому распределенной "моментальной" консистентности и не требуется. A и P есть в рамках отдельной системы. Когда-нибудь C тоже будет достигнута. Например, на десятую повторную отправку можно делать алерты и идти ругаться с владельцами лежащего сервиса и девопсами. Т.е. чинить availaiblity/consistency. В рамках eventual consistency уже могут быть различные варианты и техники реализации (те же CRDT-типы в разных вариациях). Ну и вообще, у нас же "Representational State Transfer". У нас операций нет. Мы просто иногда делимся представлением своего локального состояния. В этом плане отправка состояния по HTTP мало чем отличается от "асинхронной отправки". Ну да, мы поделились своим состоянием. Сервер когда-нибудь поделился своим. И мы должны более-менее одинаково обрабатывать ситуации, когда ответ пришел синхронно (в ответ на "первый" запрос) и асинхронно (в ответ на повторо или что-то само изменилось на сервере и он послал уведомление в очередь сообщений).