State Transitions in ReST API

Martyn Taylor mtaylor at redhat.com
Tue Dec 11 11:41:36 UTC 2012


Gentlemen,

We discussed how to model state transitions in the ReST API in the Tech 
Cabal and also offline for those who had particularly strong views.  One 
of the objections brought forward was how to distinguish between clients 
(end users or applications) requesting state changes.  For example: A 
developer decides he wants to terminate his running instances and system 
services that are used to notify conductor of when an instance has 
changed state.  For example db-o-matic wants to tell conductor that the 
instance has now started.

After some deliberation offline between myself and sseago and without 
objections from the Tech Cabal.  We decided that the services and the 
end users should access different APIs and we should not add complexity 
into the end user API in order to support these system services.

With this behind us.  We then were able to move forward to make a 
decision on how to handle requests from a user to transition between 
states.  Like in the developer example above.

It was agreed that treating the State on an instance as simply an 
attribute on the resource (and not an action) was more inline with the 
ReST principal (Since adding actions breaks ReST principal of having a  
unified interface - in our case the unified interface is defined by HTTP).

So, this now brings us to how we should represent these resources. I 
think this is something that can and should be decided on list.  I have 
included below my opinion on how this should be represented, please add 
in your own comments.

==

So in my opinion we should model a state machine as an independent 
resource.  When  client wants to change the state of an instance, it 
looks at the state machine to figure out what are the possible states I 
can move to now.  The instance can hold a reference to it's current 
state and the state machine.

A simple example here: https://gist.github.com/4257951

Regards

Martyn





More information about the aeolus-devel mailing list