Quoting [Sam Johnston] (May 13 2009):
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?
Yes, me, I don't think HATEOAS should be applied in this context. But I realise/accept that I maybe the only one with that opinion - thats ok. So I'll say it here one last time, for the record, and then will shut up: "a static simple state model allows for very simple clients. Extensions can be defined via substates, or additional transitions." Best, Andre.
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. Sam
References
1. mailto:roger.menday@uk.fujitsu.com 2. mailto:roger.menday@uk.fujitsu.com
-- Nothing is ever easy.