The REST standard defines how different types of web requests should behave. Some HTTP methods are naturally "safe" or idempotent by design, meaning the specification expects them to behave predictably even when repeated. Others are designed to create new data and require extra care to make them safe for retries.

According to RFC 9110, several standard methods are inherently idempotent. Repeating these actions should not change the state of the server beyond the initial request.

• GET: This method retrieves data. Since it doesn't change anything on the server, you can call it a million times and the resource remains the same.
• PUT: This method replaces a resource entirely. If you update a user’s email to "user@example.com" three times, the final state is still that the email is "user@example.com."
• DELETE: This removes a resource. If you delete "Order #123" and then try to delete it again, the order stays deleted. The result (the order is gone) remains the same.

Some methods are not idempotent because their primary job is to change data in a way that creates something new or modifies a portion of an existing record.

• POST: Developers use POST to create new resources. Without idempotency logic, sending the same POST request twice (like "Submit Payment") would typically result in two separate records—and two charges to the customer.
• PATCH: This method applies partial updates. While it can be made idempotent, it often isn't by default because repeating a relative change (like "add 5 to the balance") would result in a different final value each time it's called.

1. Generate a unique key: The client creates a unique string (like a UUID) and includes it in a custom HTTP header.
2. Intercept and validate: The server checks a high-speed data store like Memorystore to see if that key has been processed recently.
3. Handle the state: If the key is new, process the request and save the result. If it's a duplicate, return the stored result immediately without re-running business logic.