Use POST for delete/update in Rest?

Question

I understand (From accepted answer What is the difference between HTTP and REST?) that REST is just a set of rules about how to use HTTP

Accepted answer says

No, REST is the way HTTP should be used.

Today we only use a tiny bit of the HTTP protocol's methods – namely GET and POST. The REST way to do it is to use all of the protocol's methods.

For example, REST dictates the usage of DELETE to erase a document (be it a file, state, etc.) behind a URI, whereas, with HTTP, you would misuse a GET or POST query like ...product/?delete_id=22

My question is what is the disadvantage/drawback(technical or design) If I continue to use POST method instead of DELETE/PUT for deleting/updating the resource in Rest ?

Answer 1

My question is what is the disadvantage/drawback(technical or design) If I continue to use POST method instead of DELETE/PUT for deleting/updating the resource in Rest ?

The POST request is not Idempotent but the DELETE request is Idempotent.

An idempotent HTTP method is a HTTP method that can be called many times without different outcomes

Idempotency is important in building a fault-tolerant API.

Let's suppose a client wants to update a resource through POST. Since POST is not an idempotent method, calling it multiple times can result in wrong updates. What would happen if you sent out the POST request to the server, but you get a timeout. Did the resource actually get updated? Did the timeout happen when sending the request to the server, or when responding to the client? Can we safely retry again, or do we need to figure out first what happened with the resource? By using idempotent methods, we do not have to answer this question, but we can safely resend the request until we actually get a response back from the server.

So, if you use POST for deleting, there will be consequences.

Answer 2

From a purely technical viewpoint, I am not aware of any real drawbacks. Others mentioned idempotency, but that does not come just by using DELETE, you still have to implement it anyway.

Which leaves us with design considerations:

• Your clients (or rather the programmers programming against your API) might reasonably expect the DELETE method to delete things and the POST method to add things. If you don't follow that convention, you confuse them.
• If you use POST for both deleting and adding things, you have to invent another way of telling what actually to do. Surely this isn't very hard, but it makes your API more complicated for no good reason.
• For both these reasons, you will need more and better documentation, since you're not following RESTful principles, which are already documented.