actually, wait, PATCHing "running" is cheating. You've got a RESTful Zeno's paradox where you go from stopped to running with no time in between; where's the "starting" state? What starts immediately? And in what sense can it then restart? How does restarting alter its state?
-
-
-
For the sake of argument, say the HTTP request doesn't return until the thing is started
End of conversation
New conversation -
-
-
Admit to yourself that REST is insanity which makes error types straddle layer boundaries, and give up? Though the answer to anything RESTFUL is eventually: "POST" (to "create" a request to perform an action), followed by "GET" to verify the status of that action.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Give up and POST
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I would just make start and restart endpoints that accept POSTs.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
there's no rule that resources can't undergo state changes "behind the scenes". make a "restarting" state, PATCH that, let some other actor (the thing itself, a liveness probe, whatever) switch it to "running" when it comes back up
-
This Tweet is unavailable.
- 1 more reply
New conversation -
-
-
POST /artifact/starts?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Ansible’s `service` module, which isn’t HTTP but faces a similar problem, uses a state named “restarted” to do that.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
define "restarting" to be another valid state, and PATCH that.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.