A soft delete flags a record — deleted_at, status: deleted — instead of removing the row. The data stays for auditing, undo and referential integrity, while the API treats it as gone. That lets the API answer 410 Gone for a deleted resource, which is more informative than 404 Not Found: it says the identifier was valid and the thing is deliberately no longer available.
Every read has to exclude flagged rows, including list endpoints, search and counts. A GET on a soft-deleted id returns 410, a second DELETE returns 410 or 404 rather than 204, and a purge job eventually removes the data for good, often after a retention period that privacy law may dictate.
That soft-deleted data is gone. It is still in the database, in backups and often in search indexes; for personal data, a soft delete alone does not satisfy an erasure request. And a list endpoint that forgets the filter resurrects deleted records for every client.
DELETE /protocol/v1/documents/{id} as admin, then GET the same id: the answer is 410, not 404. The Shop API's expired coupons and the World Cup and FIBA cancelled tickets answer 410 the same way.
All glossary terms · Testing techniques · All 39 mock REST APIs
Last updated