3 ms·
The resource you are changing is the booking resource identified by /booking/:id I would go with PUT /booking/:id with a status of canceled. This makes sense
by jtchang 15y ago
The resource you are changing is the booking resource identified by
/booking/:id
I would go with PUT /booking/:id with a status of canceled.
This makes sense to me because of the semantics of traditional FSM.
You are going from some state (active) to (cancelled). You are not dictating the resulting state, only that you would like to set the status to cancelled.
PUT can return an error in which case the transition failed.
It can return success and the transition is good.
- glenjamin 15y agoThis 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.