REST сталкивается с такой же проблемой, как веб-службы на основе SOAP в отношении атомных транзакций. Отсутствует связь с состоянием, и каждая операция немедленно совершается; выполнение ряда операций означает, что другие клиенты могут видеть промежуточные состояния.
Если вы, конечно, не позаботитесь об этом по дизайну. Сначала спросите себя: есть ли у меня стандартный набор атомных операций? Это обычно происходит. Например, для банковской операции удаление суммы с одной учетной записи и добавление одной и той же суммы в другую учетную запись часто является необходимой атомной операцией. Но вместо того, чтобы экспортировать только примитивные строительные блоки, REST API должен предоставить единую операцию «переноса», которая инкапсулирует весь процесс. Это обеспечивает желаемую атомарность, а также делает клиентский код намного проще. Эта оценка известна как услуги с низкой степенью детализации, или высокоуровневые пакетные операции.
Если нет простого предопределенного набора желаемых последовательностей атомной последовательности, проблема более серьезная. Общим решением является командный шаблон . Определите один метод REST, чтобы разграничить начало транзакции, а другой - разграничить его конец (запрос «совершить»). Все, что отправлено между этими наборами операций, ставится в очередь сервером, но не передается, пока не будет отправлен запрос на коммит.
Этот шаблон значительно усложняет работу сервера - он должен поддерживать состояние для каждого клиента. Как правило, первая операция («начать транзакцию») возвращает идентификатор транзакции (TID), а все последующие операции, вплоть до и включая фиксацию, должны включать этот TID в качестве параметра.
Это хорошая идея для обеспечения тайм-аута транзакций: если слишком много времени прошло с момента первоначального запроса «начать транзакцию» или с последнего шага, сервер имеет право прервать транзакцию. Это предотвращает потенциальную атаку DoS, которая заставляет сервер тратить ресурсы, удерживая слишком много транзакций открытым. Конструкция клиента должна иметь в виду, что каждая операция должна быть проверена для ответа на тайм-аут.
Также рекомендуется разрешить клиенту прервать транзакцию, предоставив API «отката».
Обычная забота, требуемая при разработке кода, который использует несколько параллельных транзакций, применяется, как обычно, в этом сложном сценарии проектирования. Если это вообще возможно, попробуйте ограничить использование транзакций и вместо этого поддержите пакетные операции высокого уровня.
Я не принимаю кредит этой информации, я просто директор, заслуга This article
Также почитайте Transactions in REST?
Вы можете получить несколько полезных примеров кода здесь http://www.it-soa.eu/en/resp/atomicrest/userguide/index.html