State Transitions in ReST API

Martin Povolny mpovolny at redhat.com
Mon Dec 17 18:55:42 UTC 2012


Please see below my points on the topic.

The Conductor should abstract away the differences between the cloud providers.
If the abstraction on Deltacloud side is insufficient, then Conductor should do
it.

If different state machines are needed to handle instance launches at different
cloud providers, then be it. But shield the user of Conductor from this.
Abstract it into one state machine, hide the complexity. Don't move the problem
towards the user.

Sure, there is a different state machine needed for image, deployable and
instance. But give the user just these and not image, deployable and instance
state machine per provider!

I believe that figuring out how to do this right and providing the client a
comfortable workflow is a crucial part of the mission of our project. Much more
important that having clean code and Rails Way REST API.

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.

Then, please, implement an action or queue resource. If the consumer of the API
is forced to poll, then, please, make just one place to poll. Let the state
changes be done by actions that are queued, let each action have a unique id
and have a single resource to query when finding out the state of the actions.

Don't force the user to poll for changes on instances, images, deployments etc.

Do it that way, in a single place. Later on you can even change just that one
place to add some callbacks or provide an alternative mechanism for working
with the queue.

And, please, don't forget to add a method that returns state of multiple
actions in one request!

I have a feeling that I have read in this conference a mail suggesting the CIMI
spec as a sort of reference document on how to do REST so let's take this idea
from there.

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.

Happy Hacking!

--
Martin Povolny <mpovolny at redhat.com>
tel. +420777714458


More information about the aeolus-devel mailing list