Really, handling soft and hard deletes can be a mess, if you think of it.
Earlier in the Open Event server project, we had a Boolean field called is_trashed which was set to true if a record was soft-deleted. That worked just fine, until there came a requirement to get the time at which the record was deleted. So duh… we added another column called deleted_at which would store the time at which the record was soft-deleted. And it all started working fine again.
But, shortly we realised it was bad design to have a redundant Boolean field is_trashed. So it was decided to remove the is_trashed field and only keep the deleted_at column at all places. If the deleted_at field contained a date, it would mean that the record has been soft deleted at that point of time. If the field was still NULL, then the record has not been soft deleted. That ends up the database aspect of implementing soft-deletes. Let’s move on to the API part then.
We are currently in the process of decoupling our front-end and back-end. And the API server for the same is in active development. We’ve been using flask-rest-jsonapi for the same purpose. So, the first thing that popped up in our minds, when we got around handling soft-deletes was the following.
Should the API framework implement soft-deletes for each API by itself, or should the individual API logic take care of it ?
After some discussion, it was decided to let the framework handle it for each API, so that the implementation remains uniform and obviously a little less headache for the developers. In our custom copy of flask-rest-jsonapi, we also added an option to turn off the soft deletes across the whole API. Turning it off for each resource is also in our road map and would be soon implemented in the future.
Now talking about the API itself, for GET endpoints by default soft-deleted records should not be retrieved. Retrieving all the records irrespective of whether it is soft-deleted or not and letting client figure out which records are deleted is a sign of bad design. If the client wants to retrieve the deleted records, it can do so by passing a query parameter is_trashed set to true.
Following is the URL pattern followed for the same, for the sake of the example, assume that the event with id 1 is soft-deleted:
GET /events?with_trashed=true # get all events including the soft-deleted events GET /events/1 # send a 404 exception GET /events/1?with_trashed=true # retrieve relevant data
For DELETE request:
DELETE /events/1 # soft-delete the event DELETE /events/1?permanent=true # hard-delete the event
Relevant links:
- https://stackoverflow.com/questions/2549839/are-soft-deletes-a-good-idea
- http://abstraction.blog/soft-vs-hard-delete/