Trying to understand the core concept of idempotent and safe methods, but I didn't get clarity. As per my analysis
Http Methods are categorized as follows.
Help me understand with more details w.r.t internal mechanism of HTTP methods on server side and how safe differ from idempotent
Is there any other characteristics available to describe the idempotent and safe methods other than resource modification and product same result.
Help me understand with more details w.r.t internal mechanism of HTTP methods on server side and how safe differ from idempotent
Both safe and idempotent describe the semantics of handling a request.
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.
Safe methods are queries, in the cqrs sense - they don't change anything, they typically include a read of the state of the resource, but not a modification of the state of the resource.
Safe request handling leaves the resource in the same state, so a safe method is necessarily also idempotent.
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.
What idempotent request handling means is that if a client sends a request, and doesn't get an answer, the client can repeat the request.
Idempotent request handling basically means that the server calculates the final state of the resource from the request alone (without considering the current state of the resource). When handling the message a second time, the same new state will be calculated and applied.
This is roughly analogous to assigning a value.
// the previous value of x was 10, say
set(x, 7) // and now the value of x is 7
set(x, 7) // and now the value of x is still 7
In HTTP, the methods PUT and DELETE are defined to have idempotent semantics. Notice what these methods have in common: the client knows what the final state of the resource should be, and is asking the server to make it happen.
If your handling of a request instead is analogous to
// the previous value of x was 10, say
increment(x, 7) // and now the value of x is 17
increment(x, 7) // and now the value of x is 24
then your handling of the request is not idempotent.
Note that it is the semantics that are important here. Here's what Fielding had to say in 2002
HTTP does not attempt to require the results of a GET to be safe. What it does is require that the semantics of the operation be safe, and therefore it is a fault of the implementation, not the interface or the user of that interface, if anything happens as a result that causes loss of property (money, BTW, is considered property for the sake of this definition).