Menu
How could the PUT method be idempotent but not safe? Can someone explain it out?
HTTP Method Idempotent Safe
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no
457
Several common HTTP methods are safe: GET , HEAD , or OPTIONS . All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe. Even if safe methods have a read-only semantic, servers can alter their state: e.g. they can log or keep statistics.
Idempotent Methods in REST. REST APIs use HTTP methods such as POST, PUT, and GET to interact with resources such as an image, customer name, or document. When using an idempotent method, the method can be called multiple times without changing the result. For example, using GET, an API can retrieve a REST resource.
Idempotency is important in building a fault-tolerant API. Suppose a client wants to update a resource through POST. Since POST is not a 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.
All safe methods are idempotent, as well as PUT and DELETE . The POST method is not idempotent.
Safe method doesn't change anything internally (resources)
Safe methods are methods that can be cached, prefetched without any repercussions to the resource.
Idempotent method doesn't change anything externally (response)
idempotent HTTP method is a HTTP method that can be called many times without different outcomes.
153
It's all in the specification:
4.2.2. Idempotent Methods
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://greenbytes.de/tech/webdav/rfc7231.html#idempotent.methods)
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
