Timeline for answer to Implementing the command pattern in a RESTful API by Gary
Current License: CC BY-SA 3.0
Post Revisions
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 27, 2013 at 4:39 | vote | accept | Mithir | ||
| Jan 25, 2013 at 9:28 | history | edited | Gary | CC BY-SA 3.0 |
Switched to transaction
|
| Jan 25, 2013 at 7:18 | comment | added | Gary | Fair enough just rename it to Transaction. | |
| Jan 25, 2013 at 6:20 | comment | added | Mithir | @GaryRowe about the edit, what you are describing isn't a deposit, I think names are important here in order to distinguish different actions... Is it the same if I call it something like CancelledDeposit? | |
| Jan 25, 2013 at 1:18 | comment | added | Evan Plaice | (cont) Database logs use transactions in a similar manner. That's why it's possible to replicate and/or rebuild a dataset using only the logs. As long as the transactions are replayed in the chronologically, it should be possible to rebuild the dataset from any point in its history. Removing mutability from the equation ensures consistency. | |
| Jan 25, 2013 at 1:04 | comment | added | Evan Plaice | @Mithir I was describing the accounting rule. In a standard double-entry bookkeeping system you never remove transactions. History once committed is considered immutable to keep people honest. In your case you could still use a DELETE action but on the back-end (ex general ledger database table) you'd add another transaction representing crediting (ie giving back) the money back to the user. I'm no bean counter (ie accountant) but it's one of the standard practices taught in a "Principles of Accounting I" course. | |
| Jan 24, 2013 at 17:25 | comment | added | Gary | OK, I've edited my answer accordingly. | |
| Jan 24, 2013 at 17:25 | history | edited | Gary | CC BY-SA 3.0 |
More detail
|
| Jan 24, 2013 at 16:32 | comment | added | Mithir | @GaryRowe Your answer was very informative, but can you please suggest an alternative? | |
| Jan 24, 2013 at 15:07 | comment | added | Mithir | @GaryRowe So it's still a resource no? this view of interactions of the user, I can hide the creation but I need to expose retrieving no? | |
| Jan 24, 2013 at 12:16 | comment | added | Gary | @Mithir I would avoid exposing action at all - it's fine as an implementation approach. Generally, it is useful to treat user interactions with resources as entries in a (non-financial) ledger to allow a view through time of their work. | |
| Jan 24, 2013 at 8:25 | comment | added | Mithir | @EvanPlaice Why can't I just undo the action? | |
| Jan 24, 2013 at 8:24 | comment | added | Mithir | So, if I change, in my questions, instead of Delete /action/... to Delete /deposit/... is it ok? | |
| Jan 23, 2013 at 18:56 | comment | added | Evan Plaice | +1 "technically this should not be allowed in a balanced accounting system". Somebody knows how to count beans. That statement is absolutely correct, the way to reverse would be to create another transaction crediting the funds back. General ledger entries should always be considered immutable and permanent once a transaction is completed. | |
| Jan 23, 2013 at 15:00 | history | answered | Gary | CC BY-SA 3.0 |