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

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



M>Мы уже более-менее согласились на eventual consistency.

Поэтому я и написал про асинхронные вызовы.

M> В рамках eventual consistency уже могут быть различные варианты и техники реализации (те же CRDT-типы в разных вариациях).

И все они сильно сложнее простого синхронного вызова.

M> Ну и вообще, у нас же "Representational State Transfer". У нас операций нет.

Есть. Про verb в HTTP слышал?

M> Мы просто иногда делимся представлением своего локального состояния.

Давай посмотрим на определение, раз уж ты о терминах заговорил:

The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state machine) where the user advances through the application by selecting links (e.g. http://www.example.com/articles/21), resulting in the next resource's representation (the next application state) being transferred to the client and rendered for the user.

Тут, как видишь, нет ничего про "делимся представлением". Здесь есть про переходы по ссылкам (ака операции), которые приводят к изменению состояния.

M> В этом плане отправка состояния по HTTP мало чем отличается от "асинхронной отправки".

Под асинхронной отправкой я подразумевал менее абстрактные вещи (так что почти все можно асинхронным обозвать). Например когда API использует 202 код, поллинг, хттп-колбеки етц.
С той же оплатой, к примеру — реальные платежные системы, конечно, имеют и синхронное API, и его даже используют. Но при его использовании в 99% случаев начинаются проблемы (лично несколько раз такое лечил в чужих проектах). А нормальный API подразумевает нотификации. Т.е. сервис оплаты по заданному url сам тебя дергает, когда оплата проходит. В промежутке до прихода этой нотификации заказ находится в промежуточном состоянии.
Вот такой подход (та самая eventual consistency) — работает. Но он сильно сложнее по всем параметрам, чем простая синхронная реализация, когда ты просто говоришь POST, а в ответ тебе либо 200, либо ошибка. Поэтому рядом и существует хоть и полурабочее, но простое синхронное апи.

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

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



M>Мы уже более-менее согласились на eventual consistency.

Поэтому я и написал про асинхронные вызовы.

M> В рамках eventual consistency уже могут быть различные варианты и техники реализации (те же CRDT-типы в разных вариациях).

И все они сильно сложнее простого синхронного вызова.

M> Ну и вообще, у нас же "Representational State Transfer". У нас операций нет.

Есть. Про verb в HTTP слышал?

M> Мы просто иногда делимся представлением своего локального состояния.

Давай посмотрим на определение, раз уж ты о терминах заговорил:

The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state machine) where the user advances through the application by selecting links (e.g. http://www.example.com/articles/21), resulting in the next resource's representation (the next application state) being transferred to the client and rendered for the user.

Тут, как видишь, нет ничего про "делимся представлением". Здесь есть про переходы по ссылкам (ака операции), которые приводят к изменению состояния.

M> В этом плане отправка состояния по HTTP мало чем отличается от "асинхронной отправки".

Под асинхронной отправкой я подразумевал менее абстрактные вещи (так то почти все можно асинхронным обозвать). Например когда API использует 202 код, поллинг, хттп-колбеки етц.
С той же оплатой, к примеру — реальные платежные системы, конечно, имеют и синхронное API, и его даже используют. Но при его использовании в 99% случаев начинаются проблемы (лично несколько раз такое лечил в чужих проектах). А нормальный API подразумевает нотификации. Т.е. сервис оплаты по заданному url сам тебя дергает, когда оплата проходит. В промежутке до прихода этой нотификации заказ находится в промежуточном состоянии.
Вот такой подход (та самая eventual consistency) — работает. Но он сильно сложнее по всем параметрам, чем простая синхронная реализация, когда ты просто говоришь POST, а в ответ тебе либо 200, либо ошибка. Поэтому рядом и существует хоть и полурабочее, но простое синхронное апи.