Транзакция в службе REST WCF

Ответ 1

Вот цитата из Роя Филдинга, парня, который придумал термин REST

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

... на данный момент я считаю "транзакцию отдыха" быть оксюмороном.

Это от message в списке обсуждений REST от 9 июня 2009 г.

Ответ 2

Я в основном согласен с Роем Филдингом, приведенным в ответе Даррела. Вы никогда не должны подвергать аппликацию приложения, как транзакции с базами данных, через веб-службу RESTful. Однако вы можете подходить к распределенным транзакциям более функциональным способом.

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

Служба подарочного ваучера предоставляет URL-адрес для запуска коллекции:

/gift-voucher/{gift-voucher-id}/collection

Запрос на этот URL-адрес создаст и сохранит оговорку для подарочного ваучера. В ответе содержится URL-адрес резервирования:

/gift-voucher/{gift-voucher-id}/collection/reservation/${reservation-id}

Этот URL-адрес может быть POSTED или DELETEd, чтобы соответственно выполнять или отменять подарочный ваучер.

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

Ответ 3

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

Возможно, вы захотите проверить ADO.NET Dataservices, хотя это слой поверх WCF REST.

См. сообщение в блоге командой ADO.NET DataServices об этом.

Марк

Ответ 4

Вот недавняя дискуссия по теме: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/e66651c0-9202-4049-a8f4-55971b8b359d

В основном это говорит: один запрос не поддерживает транзакции, и нет смысла их поддерживать, поскольку только один объект и операция CUD задействованы в одном запросе POST/PUT/DELETE. Но транзакции могут быть реализованы на стороне сервера:

• с помощью пакетных запросов (весь пакет запросов POST/PUT/DELETE отправляется за один шаг от клиента к серверу)
• и используя конвейер обработки (начать транзакцию в событии Обработка и зафиксировать/отменить транзакцию в событии Обработанное)