Если транзакции по REST недостижимы, как REST может когда-либо быть действительно полезным? [закрытый]

Если вам нужны транзакции в приложении ReST в функции ReST API, обычно это происходит потому, что ваш технический специалист по веб-сервису все еще гулит.

Давайте посмотрим на это с другой стороны.

Мыльные поисковые системы: Откройте транзакцию, создайте запись о клиенте, создайте запись о заказе, подтвердите транзакцию.

ReST гуглит: Спросите сервер, что делать. Сервер говорит «создать ресурс клиента», поэтому POST / customers. Сервер говорит: «Теперь создайте заказ, если хотите», клиент создает заказ, следуя форме.

В ReST протокол приложения выражается в терминах ресурсов, которые создаются и которыми управляются, а не в терминах данных, которые имеют границы транзакций.

Если вы хотите иметь длительную транзакцию, охватывающую все эти операции, ее решает инициировать сервер , а не клиент.

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

Действительно, если вы не выполняете ReST и пытаетесь использовать RPC через http, у вас возникнут проблемы с отсутствием транзакций.

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

REST не может быть другим, кроме корня транзакции. Вы не можете начать транзакцию, затем выполнить две операции REST и операцию с базой данных, а затем зафиксировать их все вместе. Это похоже на ситуацию с веб-службами ASMX в .NET. Они могут быть корнем транзакции, но это все. Они были успешными в течение многих лет, пока не был представлен WCF, поддерживающий WS-Transactions. Даже сегодня при использовании WCF большинство операций веб-служб не обязательно должны быть транзакционными в том смысле, о котором вы спрашиваете.

Я знаю очень успешные системы онлайн-учета (SaaS), в которых есть нетранзакционный API на основе REST для создания, получения и управления счетами и т. Д. широко известны своим API и простотой интеграции их системы с другими сторонами. API прост в обслуживании, его можно использовать на различных платформах, а обеспечение обратной совместимости достаточно просто.

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

Иногда недостаточно того, что идеально.

Это интересная тема. Как вы упомянули, SOAP уже имеет такую ​​функциональность, но потребовалось много лет, прежде чем SOAP созрел до такой степени, что люди будут рассматривать возможность обеспечения реальной безопасности и транзакций с ним. До этого это была CORBA.

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

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

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

Например, классический банковский перевод. Предположим, я хочу переместить 100 долларов из учетной записи A в B:

Begin Transaction
  /Debit  A, $100  
  /Credit B, $100
Commit Transaction

Это можно было бы переработать следующим образом:

 /Transfer  A, B, $100  

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

Я уверен, что есть множество примеров, когда удобнее выполнять набор операций «все или ничего» (и мне любопытно, что люди могут придумать, чтобы их решить), но я обычно переделываю вещи в этом способ.

Фактически, транзакции в REST работают почти так же, как транзакции должны работать в традиционных сервисах SOAP.

Транзакции в стиле RPC, когда клиент выдает команду «начать транзакцию» (или некоторую операцию, которая неявно начинается, но не фиксирует транзакцию), за которой следуют некоторые дополнительные операции, за которыми следует еще одна неявная / явная команда «завершить транзакцию». , устарели. Мир веб-сервисов давно отошел от модели RPC; RPC / закодированный в SOAP даже не совместим с WS-I!

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

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

В REST у вас есть ресурсов вместо сообщений , но концепция действительно очень похожа. Вместо сообщения OrderRequest клиент отправляет ( PUT ) ресурс Order , и этот ресурс должен содержать всю ту же информацию, необходимую для завершения транзакции. По общему признанию, если вы пытаетесь выполнить сложную оркестровку, вы можете найти REST немного громоздким по сравнению с SOAP, но это не значит, что вы не можете продолжать использовать REST для своего внешнего интерфейса , просто это SOAP будет лучше служить вам для ваших внутренних сервисов.

Однако в действительности в 99% случаев людям не нужны сложные WS-транзакции. Я знаю это, потому что почти исключительно использую SOAP (WCF) и редко использую WS-Transactions.

В REST «состояние» зависит от клиента. Сервер сообщает клиенту: «Вот вся информация, которую вы должны предоставить мне, чтобы создать этот ресурс (завершить эту транзакцию)». Но эта пустая форма на самом деле не начинает транзакцию. Фактически предоставить информацию зависит от клиента - так сказать, заполнить форму.То, что делает клиент во время заполнения формы, не волнует сервер; когда клиент, наконец, отправляет готовую форму на сервер, она полностью проверяется. Это похоже на Единицу работы, за исключением того, что клиент отслеживает «работу».

Надеюсь, это дает лучшее представление о том, как могут быть транзакции и достигаются через REST. Они просто полагаются на более широкую концепцию сообщений / ресурсов и форму оптимистичного параллелизма.

Я собираюсь предположить, что когда вы говорите о транзакциях, вы говорите о распределенном протоколе Two Phase Commit.

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

Пэт Хелланд, который раньше работал в Amazon, а теперь работает в Microsoft, написал статью Life beyond Distributed Transactions. В статье автор делает следующее заявление:

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

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

Возможно, REST будет успешным, потому что он не поддерживает транзакции. Вот цитата Роя Филдинга, парня, который придумал термин REST

Если вы обнаружите, что вам нужен протокол распределенных транзакций, то как вы можете сказать, что ваша архитектура основана на REST? I просто не могу понять, как вы можете перейти от одной ситуации (использования RESTful состояния приложения на клиенте и гипермедиа для определения всех состояний переходов) к следующей ситуации необходимости распределенного согласования семантики транзакций, где клиент должен сказать серверу, как управлять своими собственными ресурсами.

... пока что я считаю "rest транзакция" оксюмороном.

Это из сообщения в списке REST-discuss от 9 июня 2009 года. Я не могу дать ссылку, потому что Yahoo groups бесполезен.

Я думаю, что транзакции с использованием REST действительно достижимы. Представьте транзакцию как ресурс, который вы можете создать (начать), редактировать (разместить изменения) и удалить (зафиксировать, откатить). Изменения, опубликованные в транзакции, не должны изменять глобальное состояние до тех пор, пока транзакция не будет зафиксирована, а во время фиксации вы можете применить любые правила согласованности глобального состояния, которые вам понадобятся. Ресурс транзакции, конечно же, будет защищен с помощью правил авторизации.

Вы уже упомянули общую иллюстрацию для этой концепции:

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

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

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

Взгляните на OpenStreetMap API . Я думаю, что это своего рода «REST», и он обеспечивает своего рода «транзакции», называемые там «наборами изменений». Это то, что вам нужно?

Потому что не каждая система требует транзакций.