如何为状态机或有限自动机实现 RESTful 资源 [英] How to implement a RESTful resource for a state machine or finite automata
问题描述
我是 Rails 和 REST 新手，我正在尝试找出如何最好地公开由具有状态机(换句话说，是有限自动机)的域对象支持的资源.
I'm a Rails and REST newbie and I'm trying to figure how best to expose a resource that is backed by a domain object that has a state machine (in other words is a finite automata).
我见过许多将模型类设为状态机的 gem，例如 aasm、transitions、workflow，但它们都没有记录如何在面向资源的控制器中实际使用它们的示例.它们似乎都暗示状态转换是由事件"触发的，这实际上是一个方法调用.我对这意味着什么的一些问题是:
I've seen a number of gems for making a model class a state machine, such as aasm, transitions, workflow, but none of them document examples of how they are actually used in a resource oriented controller. They all seem to imply that state transitions are triggered by an "event" , which is really a method call. Some questions I have with what this implies are:
- 更新操作(PUT 方法)不合适，因为 PUT 被认为是幂等的.唯一可能的是，如果状态作为表示的一部分发送.这与事件"不一致.这是正确的吗?
- 由于事件不是幂等的，因此必须使用 POST.但是，到哪个资源?每个可能的事件都有一个子资源吗?或者，是否有一个 (/updatestate) 将要触发的事件和事件的任何参数作为其表示?
- 由于资源的状态被另一个资源可能触发的事件修改，创建操作是否应该接受状态属性(或任何其他依赖状态机的属性)的更改?
- [更新的问题] 在 UI 中公开转换的好方法是什么?由于事件不是状态，因此允许更新状态属性(以及任何其他依赖于状态转换的属性)似乎没有意义.这是否意味着应在更新操作中忽略这些属性?
推荐答案
- 更新操作(PUT 方法)不合适，因为 PUT 被认为是幂等的.唯一可能的是，如果状态作为表示的一部分发送.这与事件"不一致.这是正确的吗?
正确.
- 由于事件不是幂等的，因此必须使用 POST.但是，到哪个资源?每个可能的事件都有一个子资源吗?或者，是否有一个 (/updatestate) 将要触发的事件和事件的任何参数作为其表示?
两种方式都可以.您可以在同一应用程序中同时支持两者，事件类型的变化取决于传入文档或接收资源.就个人而言，我更愿意通过不同的文档类型来实现，但这只是我的意见.如果您确实采用多资源路线，请确保它们是可发现的(即，通过在获取其父资源时返回的文档中描述的每个资源的链接).
You can do it both ways. You can support both in the same application, with variation in event types being determined by either the incoming document or the receiving resource. Personally, I would prefer to do it by differing document types, but that's just my opinion. If you do go the multiple resources route, make sure they're discoverable (i.e., by having links to each of them described in the document returned when you GET their parent resource).
- 由于资源的状态被另一个资源可能触发的事件修改，创建操作是否应该接受状态属性(或任何其他依赖状态机的属性)的更改?
由你决定；没有真正的理由为什么您必须密切关注创作中的任何特定属性.(您可以通过说状态在创建后立即更改为状态机的正确初始状态来合理化这一点.)在我所做的状态机中，无论如何创建都是通过 POST(并且是不同的 - 相当复杂 -文档)所以整个事情都没有实际意义，但是如果您允许多个初始状态，那么在创建文档中采用这是我首选的起始状态"提示是有意义的.需要明确的是，仅仅因为用户想要它并不意味着你必须这样做；当您拒绝用户的建议时，是否要向用户投诉是您的决定.
Up to you; there's no real reason why you have to pay close attention to any particular attribute on creation. (You could rationalize this by saying that the state changes to a proper initial state for the state machine immediately after creation.) In the state machines I've done, the creation was by a POST anyway (and of a different – rather complex – document) so the whole thing was moot, but if you allow multiple initial states then it makes sense to take a "this is my preferred starting state" hint in the creation document. To be clear, just because the user wants it doesn't mean you have to do it; whether you want to complain to the user when you reject a suggestion of theirs is your call.
- 列表项
[股票答案.]
这篇关于如何为状态机或有限自动机实现 RESTful 资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
