Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so.
Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.
And perhaps I'm talking out of my ass, but the number of DELETE operations is likely vanishingly small for HTTP resources.
POST is not idempotent, DELETE is idempotent. That's a pretty significant difference. Yes, obviously, you can use POST in place of DELETE (heck, plenty of APIs have used GET in place of everything), but its not a good idea, and losing DELETE in favor of POST loses clarity.
> That is, DELETE can be semantically correct, but POST would be more so.
DELETE is both more specific about intent and more specific about the idempotence of the operation, so, no, POST would be less semantically correct for any operation where DELETE is semantically correct.
> Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.
Actually, it says that success (2xx) series codes should not be returned unless the server intends to complete the operation, and further specifies that that 200/204 codes indicate that it has enacted the operation (differing in whether a response body is included) and 202 indicates that it has accepted the request but not enacted the operation yet.
Idempotent methods are important; I'll give you that. However, the struggle between ACID and CAP theorems would suggest these are just words we will try to live by. I rather dislike having to imagine what it means for my DELETE operation to be bouncing around the network for a minute.
> unless the server intends to complete the operation
A gerund; it intends to, without any guarantee of recency, to perform the operation. The very same problem that required the operation to be idempotent; it can't be guaranteed the operation is already done, only that it intends to complete in time. A 200 will only describe the status and does not require the description to be "deleted."
Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.
And perhaps I'm talking out of my ass, but the number of DELETE operations is likely vanishingly small for HTTP resources.