This is exactly dictating the resulting state. Consider the FSM: States = (active, cancelled); Transitions = [("cancel", active -> cancelled)] If the

This is exactly dictating the resulting state. Consider the FSM: States = (active, cancelled); Transitions = [("cancel", active -> cancelled)] If the API says PUT status = cancelled, then we'd look through the transitions and find the one that matches our current state and the target state ("cancel"), then execute the associated code, the side effects of this transition - probably sending an email. We now want to refactor the cancellation model to this: States = (active, cancellation requested, cancelled) Transitions = [("cancel", active -> cancellation requested), ("confirm", cancellation requested -> cancelled)] You can see where I'm going with this already, the transition we want the user to take from the active state is the same, but the additional state means that we either have to change the API for cancellation, or have the PUT status do something other than specify the state we're moving to. This is the reason I firmly believe changes of state should be requested by naming the transition, and why I'm not entirely sold on the "best" way to do this with a "proper" RESTful architecture.