При изучении REST одна из первых вещей, вероятно, кто-нибудь заметит, что определенная семантика транзакций не определена, некоторые говорят, что это неявно против того, что REST, в то время как другие говорят, что любая попытка сделать это приведет к "заражению", системы REST.
Но мы можем сказать, что REST действительно стал популярным выбором "api", и каждый сайт в юниверсе начал показывать спокойные точки входа.
Как именно они могут использоваться без транзакционного поведения (и я говорю, что они не компенсируют)? потому что мне кажется, что одним из преимуществ REST является то, что он разбивает компоненты данных, это, по вашему мнению, открывает их для того, чтобы интеллектуальные клиенты составляли данные (и добавляли и настраивали такие скомпонованные данные) из нескольких сервисов. Но если я не могу выполнить свои изменения в этом составе данных атомарно и изолированно, то использование REST становится бесполезным.
По прошествии времени и необходимость получения серьезной информации, мы хотим получить то, что есть: просто (REST выигрывает там) и поддерживает транзакционное поведение, поэтому мы можем надежно управлять этими данными.
Теперь, я несколько раз читал конкретный аргумент в своих исследованиях, и это связано с тем, как мы должны думать о транзакциях в REST, а приведенный пример - это корзина для покупок, где вы неявно имеете изоляцию потому что тележка ВАША.
Однако я не согласен с этим аргументом: во-первых, изоляция корзины покупок просто удобна, это не изолированность транзакций. Что произойдет, если я одновременно выполняю операцию против своей тележки, пока какая-то часть моего приложения читает данные от него? Я бы не ожидал, что часть чтения моего приложения увидит данные, которые все еще находятся в транзакции.
Не говоря уже о том, что не все изменения данных имеют неявную модель транзакции, транзакции по нескольким сервисам определенно не соответствуют.
Мне кажется, что транзакции должны произойти и должны произойти таким образом, чтобы фактические вызовы REST не знали об этом (добавив, что остальная полезная нагрузка является большой, нет, но добавление заголовков в порядке).
Я прочитал несколько предложений о том, как модель транзакций может быть создана над REST, а некоторые из написанных спецификаций выглядят очень недавно.
Есть ли какие-то реальные мысли об этом? не должно быть что-то "больше", чем REST, чтобы упрощенную природу REST можно было использовать против сплошного манипулирования данными ( "кислотные" транзакции).
Если мы не ожидаем, что мы будем продвигать анте и расскажем разработчикам услуг, что если они хотят взаимодействовать в чистом мире данных, им нужно поддерживать что-то, возможно, монолитное, как мыло? или еще хуже попытаться построить свою собственную поддержку транзакций в нечто вроде REST, что делает каждую службу нестандартной и нарушает всю мощность REST?
Заранее благодарим за любые мысли.
Изменить, добавлен короткий сценарий:
Представьте клиентскую форму, которая обрабатывает создание альбома, для удобства в этом альбоме, вместо того, чтобы просить пользователя дать uri для ресурса исполнителя, они могут выбрать из списка художников (скорее всего, GET'd из каталог художников).
Для удобства использования клиент может написать имя исполнителя вручную, чтобы создать художник "inline".. в сценарии проводки код клиента понимает это, и перед отправкой запроса на создание альбома он, во-первых, пытается определить, существует ли художник, если это так, получает ури для этого художника, в противном случае создает художника и получает художников uri.
Затем клиентский код продолжает создавать альбом, это умнее обычного клиента, он не сидит прямо над REST и "тупо", но вместо этого имеет некоторое взаимодействие, которое обрабатывает более чистую логику REST.
Однако в этом случае было бы неплохо гарантировать, что художник не создан, если альбом не создан, поскольку сначала создается художник.
Это не так важно, как предполагала транзакция, но определяет набор действий, которые клиентский код предпочел бы выполнять как одну операцию (в конце концов, это делает это похожим на одну операцию на пользователь).
Единственное руководство, которое я видел для этого сценария, - это заставить клиента компенсировать действие в случае сбоя в создании альбома и специально вызвать удаление исполнителя. Но это кажется проблематичным, потому что клиент предполагает, что художник был изолирован, что маловероятно, как может быть, что произойдет, если другой клиент уже "увидел" этого исполнителя и назначил ему?
Это мои проблемы в отношении внесения изменений в данные, и в то время как есть, конечно, другие пробелы (кто говорит, что художник не может быть просто удален позже), эти действия НЕ прозрачны (т.е. действия не являются что-то автоматизированное клиентом, но что-то специально запросило у пользователя).
Я надеюсь, что это поможет осветить тему.
