The possible state transitions between the Conductor provided states
should be
part of the documentation and not a separate resource in the API. And the state
machine should remain internal.
[snip]
Back to the state machines. The reason to choose REST was that it is simple to
use. But having the API client download the state machine from Conductor and
adapt it's behaviour to the downloaded state machine does not sound simple at
all.
Hmm not sure. From the REST point of view, the API should be discoverable. Not saying
Aeolus API is or will be usable by some automated tool, but I think we should follow the
discoverability principle where it doesn't cause pain.
I think that translating this:
https://gist.github.com/4257951#file-gistfile1-xml-L9-L25
into this:
{
:running => [:stopped, ...]
...
}
... should be reasonably easy and then client gets forward compatibility for state machine
changes. But if someone doesn't care about forward compatibility, they can still
hardcode the above hash ^^ into their app. (This is what people would be forced to do if
we didn't make it discoverable, as you suggested.)
Honestly, I think the hard part here is defining those two global state machines and
making Conductor use them internally, imho it's a veteran-level task. When the state
machines are in place internally, implementing and consuming corresponding REST API should
not cause trouble. I'm curious what others think about your suggestion.
The issue of polling and long running tasks/jobs that you mentioned is very important, but
I'd like it to be a separate discussion (as this one is already getting big :) ).
Take care,
J.