REST — переходы состояний модели

В REST - revertable DELETE было дано хорошее введение в то, как моделировать изменения состояния в REST. По сути, если у вас есть ресурс с полем status, вы просто добавляете новую версию этого ресурса с полем обновления status.

В этой теме я хотел бы расширить эту модель. Допустим, у вас есть ресурс, который может находиться в двух состояниях: 1 и 2. В отличие от простой модели, описанной в процитированном посте, существует три перехода для перехода из состояния 1 в состояние 2 вместо одного.

Мой вопрос: как бы вы моделировали переходы между состояниями в REST?

Я сам не могу придумать RPC-подобный POST, который, вероятно, не очень RESTian:

POST http://server/api/x
     target_state=2&transition=3

Это изменяет ресурс x из состояния 1 в состояние 2 с помощью перехода 3.


person Zure Citroen    schedule 21.07.2011    source источник


Ответы (1)


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

Например, скажем, у меня нет дома. Я могу перейти из «бездомного» состояния в «домашнее» тремя способами: могу взять напрокат, могу купить, могу украсть. Три перехода от «бомжа» к «дому»? Не в мире машин. Либо различия существенны, либо нет. Если это не так, то для машины вообще нет смысла проводить различие. Просто ПОСТАВЬТЕ новый статус "домашний". Если да, то нам нужно расширить нашу концепцию состояния, чтобы охватить различия. Например:

         homeless
        A    A   A
       /     |    \
      V      |     V
possessor <--|---  renter
       A     |    /
        \    |   /
         V   V  V
           owner

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

Если затем вы хотите представить «бездомных» по сравнению с «в доме» (владелец|арендатор|владелец), нет проблем с представлением этого как самостоятельного вычисляемого ресурса, доступного только для чтения. Только не позволяйте никому PUT/POST к нему, так как переход неоднозначен. Также нет проблем с хранением истории переходов между состояниями в качестве дополнительного набора ресурсов, если это состояние значимо.

person fumanchu    schedule 21.07.2011
comment
Во-первых, большое спасибо за подробный ответ. Очень круто. Но я все еще не совсем уверен, что каждый переход можно легко смоделировать как состояние. Я думаю, что есть огромная разница между промежуточными состояниями и постоянными состояниями. Вы охватили вторую группу. О первой группе пример: скажем, вы можете перейти от бездомного к обладателю тремя способами: вы платите за это, получаете наследство или выигрываете в лотерею. Вы также собираетесь моделировать это как отдельные состояния? Не ведет ли это к взрыву состояний «просто ради представления различных переходов как состояний»? Как вы это видите? - person Zure Citroen; 21.07.2011
comment
[Под владельцем я имел в виду украденный. Если вы платите за это или выигрываете в лотерею, вы находитесь в состоянии владельца.] Если для вашего приложения важно, какой путь выбран, тогда да, вы должны либо использовать промежуточные состояния, либо создавать новые терминальные состояния, либо добавлять дополнительное состояние. (как ресурс для ипотеки), чтобы представить различия. - person fumanchu; 21.07.2011
comment
Хорошо, имеет смысл. Я только боюсь взрыва «виртуальных» состояний, порожденных перекрестным произведением всех возможных переходов. - person Zure Citroen; 22.07.2011
comment
@ZureCitroen - Опять же, в конечном итоге все сводится к тому, что вас волнует. Если вам на самом деле важно каждое виртуальное состояние из векторного произведения всех переходов, вам следует превратить переходы в состояния. Если вы не заботитесь о них, то это просто переходы. В машине состояний важны состояния, а не переходы. Переходы — это только средства для достижения цели. - person cdeszaq; 20.02.2012