POST:- is used to create and update resources
PUT:- is used to update existing resources
Can I use POST instead of PUT method? and If I use POST method over PUT method, what will be disadvantages?
If POST can do work of PUT method, why PUT method is required?
Can I use POST instead of PUT method?
Yes, you can. HTML forms, for example, use POST for all writes.
If POST can do work of PUT method, why PUT method is required?
It didn't use to be. In HTTP/1.0, the specified methods were HEAD, GET, and POST. PUT was relegated to Appendix D: Additional Features.
If I use POST method over PUT method, what will be disadvantages?
PUT is idempotent. POST is not.
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request....
the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
What this means is that for PUT, the client can use at-least-once-delivery of the request; repeatedly sending the same PUT message across an unreliable network until a response is received.
(This guarantee is provided by the server, communicated by the fact that a given resource accepts PUT messages. It's not free, you need to make sure that the server handles the messages correctly.)
Notice that it isn't just the client that is aware of this guarantee, but also all intermediate components (proxies) that can see the request message -- the proxy doesn't need to go back to the browser to ask the user if it is safe to retry the message -- the PUT method says the server is providing the guarantee that it is.
A POST request says "Here is some data, parse it using the handler at the specified URL, and then do something useful with it"
A PUT request says "Here is some data and a URL. If anyone makes a GET request for that URL, give them this data."
They do distinctly different things.
You could achieve the same end as a PUT request using a POST request, but the semantics for how to process the PUT request are predefined and standard.
The main difference is POST does not guarantee idempotent, and PUT must guarantee it.
Meaning, suppose you update a record to increment it, then you cannot use POST. Because each time a user makes that update the record will be different, and so the user cannot just go on trying again and again and expect the same result. With PUT update, the user is allowed to keep trying the request many times and is guaranteed that the final record and response will always be the same no matter how many times the user makes the update request.
Mostly people don’t want to give this kind of guarantee so they just use POST, which is not idempotent. But say you're not incrementing anything just putting the same file, user can expect exact same fileId and response even if he repeatedly calls, you can use PUT.
For idempotent things, you’re also allowed to do insert with PUT. So both POST/PUT can be used for insert/update (both submit data). It’s up to the dev how they want to use - some like to map CRUD to the methods - others just POST or PUT for everything depending on idempotence.
POST and PUT can help consumers of your REST api understand what is happening in your API. For example you may require some kind of token on PUT (aka update) to help ensure that the entity being updated hasn't been changed since it was read. POST might fail differently when the entity already exists vs. PUT failing only if it has been changed or failing if it DOES NOT exist. Really sounds like you need to look at some existing REST APIs and get an idea of how they work.
I believe it is up to the developer which one to use.
Lets say you are creating a record. If your ID field is empty means it is a create request. If ID is provided, then it is an update request.
Developers can distinguish it. I understand idempotent requests will guarantee that result will be same but same for the POST method if you are sending ID = 1.
We can always update record even you send the same request 1000 times.
You can also read a post here which elaborates on this point.
