I am not feeling comfortable with having a state model which will change on the fly, depending what a resource will answer. For one thing, it will make user interfaces and tools really difficult to design:
- should I add a suspend button, even if it works only sometimes? - if it worked once, will it work again? - what can I do if it does not work? I want to suspend, dammit! ;-)
I don't share your pessimism, but then again, I also think we are getting our wires crossed. I think there is a lot of help here from hateoas which does a lot to address your concerns above (??)
That was exactly the point of introducing both together - given that most of the innovation is going to happen server side, clients should be as dumb as possible. That is, it doesn't matter if a new state comes along after a client has shipped because it will be advertised as a potential transition (HATEOAS), perhaps even with the expected target state.
I totally agree.
Great. Anyone doesn't agree with the need for [and proposed solution offering] flexibility in the state model?
The temptation is to assume that infrastructure is a simple problem with a fixed domain but I can assure you this not the case - without allowing for such flexibility each implementor will find themselves having a good chance of running into functions they are not able to expose via the API, or which the API expects but which are not present (for example, if "stop" implicitly results in "destroy" should we offer "stop" at all?).
My point was I wanted to talk about the "states as verbs" model which currently on the wiki ...
So the question is do you ask a "RUNNING" resource to "STOP" by pressing a button in order to get it to the "STOPPED" state or do you update its status from "RUNNING" to "STOPPED". To me the latter is unclean because who are you to say you're going to get to that state immediately, or indeed that you'll even get there at all - updating the status of a "STOPPED" machine to "RUNNING" makes no sense if there's an operating system error that causes the boot to fail for example. I certainly prefer pressing a "START" button, having a transitional "STARTING" state with an accurate progress indicator and eventually reaching a "RUNNING" state. There's some sense in a parametrised "transition-to" function of some sort with an array of potential target states but I still think I prefer the actuator approach that we currently have.
Hi Sam, My thoughts on both your post and that of Chris too. I hope I'm reading your email correctly. I like posting to a collection, because it does give an obvious holder for the state collection, which is then my state history, should i need it. I can also publish a membership policy (which changes) of what 'types' of new resources can go into a collection. This is useful to build the payload. It is also a record of failed transitions. I don't think this ignores the possibility of a delay or failure in state change. After POSTing to the collection, returning a 202, means that is has been accepted for processing (if i understand correctly). So, there is an (implied) "in-process" sub-state. And the accepted-for- processing resource is then a good one to ask why it went wrong, if something did go wrong ... (?) That's something I don't see in the actuator approach (again I might be missing something) as I don't see that it is creating new resources. Roger
Sam
______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does not guarantee that it has not been intercepted or amended nor that it is virus-free.