State Transitions in ReST API

Scott Seago sseago at redhat.com
Tue Dec 11 14:19:21 UTC 2012


On 12/11/2012 06:41 AM, Martyn Taylor wrote:
> 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.
>
So this matches what we'd agreed to fairly closely. I just have a minor 
comment around the wording. I think the distinction here is not so much 
'end users' vs. 'services' but rather 'making state changes with the 
intent of making the resource state reflect that change' vs. 'fixing the 
state in the conductor database when the state in conductor does not 
match the state of the underlying resource' (i.e. the conductor model of 
the instance vs. the actual state of the instance in ec2) End users, of 
course, would only need access to the former sort of state change. 
Services, however, might need access to both. Essentially, one way of 
making state changes is the normal state change API that both end users 
and services may make use of. The second way is the lower-level 
highly-privileged API that essentially only services should have access to.

Scott

> 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