I took polls on my LinkedIn and X asking about what we should do in the scenario where we have previously hard deleted an item and then issue a 2nd or subsequent request to delete the same item.
The RFC doesn’t offer clear guidelines on this and there was very mixed opinions in the replies but around 57% in both polls voted for 404.


I can see validity for both approaches. On the one hand the item is gone (or never existed) so 404 seems most correct. On the other hand, the intent of the HTTP Delete request (e.g. the item does not exist on the server) has been achieved and thus returning an error code might seem unnecessary.
If clients don’t care when something has been deleted just that it has or is now not on the server, we can probably use 204 to make things a little easier. If they need to know something was previously deleted 404 might help more. We just need to ensure that the API documentation clearly specifies the expected responses.
Return status codes do not impact Idempotency
Some devs suggested always returning 204 as delete is an Idempotent operation and so the status codes should remain the same for the initial delete request when the item is actually deleted but also for 2nd and subsequent requests when it now longer can be found.
This is an incorrect reading of what Idempotency means though. A HTTP method is idempotent if the intended effect on the server of making a single request is the same as the effect of making several identical requests. To be idempotent, only the state of the server is considered.
The definition of Idempotent on developer.mozilla.org makes this clear :
