How does PUT function different than POST in REST API

Question

I have read many answers about the difference between PUT and POST. The answer provided is PUT is Idempotent in almost all answers.

When using a Put, an Id is provided and the complete entity is provided,

My doubt is, what difference does it make if we use a post method with an id as an input along with the entity. In either of the cases, a DB query has to be done to check if the data is existing or not.

So why two different methods? Is there any Difference between the two if the way they function? What extra functionality or feature does PUT technically provide over POST rather than just the verbal difference.

Answer 1

The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.

https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4

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. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

Like the definition of safe, 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.

https://www.rfc-editor.org/rfc/rfc7231#section-4.2.2

Answer 2

So why two different methods? Is there any Difference between the two if the way they function?

Not necessarily. But there is enormous difference in what they mean (semantics).

Idempotent is an important semantic difference; on an unreliable network, messages get lost. Furthermore there is no way to determine whether the lost message was the request or the response.

What an idempotent semantic allows us to do is arrange that the client resends the request if it times out waiting for a response.

Furthermore, because the idempotent promise is part of the HTTP standard itself, generic components can safely decide on their own to resend the request without needing to know anything about the domain specific context of the request.

PUT on its own also has some interesting implications:

An origin server MUST NOT send a validator header field (Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).

In your server implementation, you could use exactly the same logic to implement POST as you do PUT; but without the semantics promised by the method, generic clients can't take advantage.