[OASIS Issue Tracker] Issue Comment Edited: (CAMP-31) State change mechanism is unclear

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31768#action_31768 ] 

Tobias Kunze  edited comment on CAMP-31 at 11/21/12 11:17 AM:
--------------------------------------------------------------

In my experience, APIs become very quickly inelegant when state- and operation-oriented styles are mixed. Both are in the end just that, styles, but whatever we choose, my vote would be to keep it consistent.

To the points raised in the description:

    >  But resume/suspend are operations - not "new states".

This seems valid, the states should be called "running"/"suspended" instead

    > [...] it seems more natural to control [...] state transitions [...] with operation names

As said above, this is purely a style issue in my view. Yes, we are more used to "deploy", "start", "stop", "resume", "suspend", etc. because that's what we *do*. But it leads to resource representations with volatile fields (e.g. "current-operation: START"), which is equally odd. Typically, the assumption on a PUT or POST is that the body is a static representation. Again, this is just style, but I'd argue that me PUT'ing "a: x" on a URL and then GET'ing that same URL with "a: y" is equally odd.

    > The latter may appear more RESTful but is rather limited for controlling enterprise apps.

I don't see this. Could you elaborate?

    > (a)	There may be more than one way to get to a new state from a current state

I'd argue that the state machine is simply incorrect if that's the case. If I can transition from A to B via p or q, and that matters to me, then the state machine needs to promote the transitions to states, allowing me to transition A -> P -> B or A -> Q -> B. Of course, if we want to allow the user to simply ask to go from A to B, the API would have to come back with an error asking which intermediate step it should take.

    > (b)	There might be a need for operations that don't change state.

It doesn't appear to me as if your example is an "operation" in the sense discussed here (i.e. "deploy", "start", "stop", "resume", "suspend", etc.). Inspecting a resource seems to be a simple GET without any state change involved.


To summarize, my sense is that the REST-related issues discussed here are really just symptoms of a misconceived state machine. If we mix states and operations, the situation will only worsen.



      was (Author: tkunze):
    In my experience, APIs become very quickly inelegant when state- and operation-oriented styles are mixed. Both are in the end just that, styles, but whatever we chose, my vote would be to keep it consistent.

To the points raised in the description:

    >  But resume/suspend are operations - not "new states".

This seems valid, the states should be called "running"/"suspended" instead

    > [...] it seems more natural to control [...] state transitions [...] with operation names

As said above, this is purely a style issue in my view. Yes, we are more used to "deploy", "start", "stop", "resume", "suspend", etc. because that's what we *do*. But it leads to resource representations with volatile fields (e.g. "current-operation: START"), which is equally odd. Typically, the assumption on a PUT or POST is that the body is a static representation. Again, this is just style, but I'd argue that me PUT'ing "a: x" on a URL and then GET'ing that same URL with "a: y" is equally odd.

    > The latter may appear more RESTful but is rather limited for controlling enterprise apps.

I don't see this. Could you elaborate?

    > (a)	There may be more than one way to get to a new state from a current state

I'd argue that the state machine is simply incorrect if that's the case. If I can transition from A to B via p or q, and that matters to me, then the state machine needs to promote the transitions to states, allowing me to transition A -> P -> B or A -> Q -> B. Of course, if we want to allow the user to simply ask to go from A to B, the API would have to come back with an error asking which intermediate step it should take.

    > (b)	There might be a need for operations that don't change state.

It doesn't appear to me as if your example is an "operation" in the sense discussed here (i.e. "deploy", "start", "stop", "resume", "suspend", etc.). Inspecting a resource seems to be a simple GET without any state change involved.


To summarize, my sense is that the REST-related issues discussed here are really just symptoms of a misconceived state machine. If we mix states and operations, the situation will only worsen.


  
> State change mechanism is unclear
> ---------------------------------
>
>                 Key: CAMP-31
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-31
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Jacques Durand 
>
> (filed jointly with Tom Rutt)
> In CAMP draft there seems to be a confusion in section 6.11 about the name of a state and the name of the operation leading to that state.
> -----"{"new_state" : "<new-state-value>"} 
> Where, new_state specifies the new desired value for the application state. This specification defines two such values: "suspend", and "resume,"..."-----
> But resume/suspend are operations - not "new states".
> In fact, it seems more natural to control lifecycle (state transitions) with operation names (like in CIMI) rather than by stating the "new state". The latter may appear more RESTful but is rather limited for controlling enterprise apps.
> The specification should clarify the state-changinf mechanism. Using operation names in requests instead of "new state" has some advantages:
> (a)	There may be more than one way to get to a new state from a current state (so using state name is not enough).
> (b)	There might be a need for operations that don't change state. E.g. an op that verifies whether or not a PDP is deployable on a platform even before we try to deploy it.
> Unless we are sure (a) and (b) never apply then we can use "new state" names (in which case 6.11 still need to be fixed). But that needs some investigation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira