5 ms·
REST could accomodate for undo quite fine. The server would just have to return a resource representing the action in the response. The client could then delete
by strictfp 13y ago
REST could accomodate for undo quite fine. The server would just have to return a resource representing the action in the response. The client could then delete the action with another request, which would amount to an undo. This is analogous to the command pattern and would require more effort from the programmer, just like normal undo. You need to keep an action history and make sure that all actions are reversible.
- barrkel 13y agoIf REST follows HATEOAS fully, the back button is 90% of your undo.
- joshguthrie 13y agoI would like to know more about this implementation. I don't see how going back after a POST action is related to HATEOS.
- strictfp 13y agoHmm. This would require a representation of the complete state history in resource urls, wouldn't it? I can only come up with something like /image/edit1/edit2/edit3/edit4 where going back would bring you to /image/edit1/edit2/edit3. I suppose you can also do something state-based like /image/state4 going back to /image/state3. This would push the storage of the edit stack to the server. Is this what you mean?
- barrkel 13y agoYes; with request / responses reanimating a continuation, and with a copy-on-write tree of activation records instead of a stack. But the usability probably wouldn't be fantastic.