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

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

2616 некоторым образом устарел. А в актуальном 9110 написано так:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

Да и в 2616 еаписано вовсе не про state

the side-effects of N > 0 identical requests is the same as for a single request.

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

M>В самом HTTP для существующих глаголов есть два типа идемпотентности.

Это не два типа идемпотентности, это другой признак, называется safety.

M>Если запрос применим в состояниях s1 и s2, то состояние после выполнения запроса одно и то же: req(s1) == req(s2). На практике для безопасного повторения запросов в системах со многими акторами хотелось бы больших гарантий.

В распределенных системах это вряд ли реализуемо, так как упирается в САР-теорему. Максимум можно такое обеспечить для асинхронных операций, и то это будет та еще эквилибристика.