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.
