CODEWITHSUNDEEP
resthttpweb-serviceshttp-post
user3198603
user3198603

Reputation: 5836

Use POST for delete/update in Rest?

I understand (From the 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 the POST method instead of DELETE/PUT for deleting/updating the resource in Rest?

Upvotes: 25

Views: 50985

Answers (4)

Mehraj Malik
Mehraj Malik

Reputation: 15874

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.

Upvotes: 50

Sangram Badi
Sangram Badi

Reputation: 4274

In REST generally we know that POST use to Add something, PUT use to Edit something in existing data and DELETE is use for Delete something and POST request is not Idempotent but the DELETE request is Idempotent. Although above are definition but in my point of view We are using these methods because for better understanding that particular method is use for what purpose and by using these methods the bridge between UI developer and Backend developer will not be minimized.

if you want to use POST method instead of DELETE/PUT then there will not any impact but this is not a good coding standard.

Upvotes: -1

Sanjeev Guglani
Sanjeev Guglani

Reputation: 2484

When we use POST instead of Delete in our rest API then we are snatching power of Idempotency from client.That means,By using POST we are saying to our API user that this API can produce differnent result upon hitting multiple time.

In case of Timeout, API user have to enquiry for the resource which he had made a request to delete.Then if found,he has to made a call to POST API to delete it.

Where if same request is made using Delete method.Then we are assuring our API user that multiple calls to same method will return same result. Hence he can raise any number of request untill he gets successful deletion instead of Timeout without enquriy.

Note : Maintaining Idempotency is the duty of API maker.Just putting Delete method do not give Idempotency.

Upvotes: 4

Flo F
Flo F

Reputation: 141

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.

Upvotes: 14

Related Questions