State Transitions in ReST API

Jan Provaznik jprovazn at redhat.com
Thu Jan 10 13:27:07 UTC 2013


On 01/07/2013 12:18 PM, Martyn Taylor wrote:
> On 01/03/2013 09:44 AM, Jan Provaznik wrote:
>> On 01/02/2013 03:27 PM, Tzu-Mainn Chen wrote:
>>> ----- Original Message -----
>>>> From: "Jan Provaznik" <jprovazn at redhat.com> To:
>>>> aeolus-devel at lists.fedorahosted.org Sent: Wednesday, January 2,
>>>> 2013 4:48:31 AM Subject: Re: State Transitions in ReST API
>>>>
>>>> Hi, my late $0.2: Conductor abstracts (should abstract) from any
>>>> provider specific state transition differences, the state machine
>>>> should be same in all cases. I think that just documenting state
>>>> transitions in API doc would be sufficient solution.
>>>>
>>>> With current Conductor capabilities, I can't think of any
>>>> reasonable use case where a developer would choose processing state
>>>> machine API. As I understood this API is required by Winged Monkey
>>>> folks - could you guys please confirm that you want/need this API?
>>>>
>>>> Not sure if it's a blocker for you but implementing this feature
>>>> (state machine + API) will take at least 2 sprints (optimistic
>>>> estimation).
>>>>
>>>> Jan
>>>>
>>>
>>> From the Winged Monkey perspective, we can work with either solution,
>>> so I think we'd prefer the one that gets it out the door the fastest
>>> :)
>>>
>>> Mainn
>>>
>>
>> Great, so in first iteration of instance/deployment API we could use
>> simplified format which can be finished this sprint:
>> https://gist.github.com/4442224#file-gistfile1-txt-L1
>> So Winged Moneky folks will not be blocked by waiting on state machine
>> implementation.
>>
>> Then once we implement state machines in Conductor and it turns out
>> that it makes sense to expose them through API, we can extend to the
>> format agreed by Jirka and Martyn without breaking API compatibility:
>> https://gist.github.com/4442224#file-gistfile1-txt-L11
>>
>> Jan
> Jan.
>
> This simple approach looks reasonable.
>
> I have just a question about how users update the resource in this
> situation?  If we do not want to prevent the previously agreed upon
> approach.  Then we should treat state as resources and therefore PUT the
> instance with the desired state.  In your example there is now way to
> determine which states the resource can move to or get a list of states.
>
> In your example does a client sets the state value to STOPPED.  Or does
> this first iteration not support updating states on instances via the API?
>
> Cheers
>
> Martyn
>
> Martyn

The simplified proposal above doesn't care about sending instance 
actions which turned out to be tightly related to this. We discussed 
this on IRC yesterday, my personal preference would be handling instance 
actions through separate resource but I'm not REST expert and I will not 
implement the API so I'm OK if the proposal above will be ignored.

Jan


More information about the aeolus-devel mailing list