2.3 Idempotency Flashcards
What is idempotency?
Idempotency essentially means that the effect of a successfully performed request on a server resource is independent of the number of times it is executed.
The property of an operation that ensures performing the same action multiple times produces the same outcome as doing it once.
Idempotent HTTP methods include GET, PUT, DELETE, HEAD, OPTIONS and TRACE and by utilizing them, developers are able to take care of retries and errors to ensure that the APIs being created do not fluctuate in performance and are consistent to use at any one time.
Regardless of whether you want to provide users with the possibility of changing their profiles, cancel orders, or delete records, you can use idempotent APIs to guarantee the success and consistency of your actions.
How does idempotency apply to APIs?
A client can send the same request multiple times without causing unintended consequences, such as duplicate entries or repeated side effects.
What happens if a user experiences a timeout during an online payment API call?
The payment API is called again as part of the retry mechanism, potentially leading to multiple charges without idempotency.
What is the impact of idempotency on user account registrations?
Without idempotency, duplicate user accounts might be created if the registration form is submitted multiple times.
Why is idempotency critical for reliability and consistency?
It prevents undesired duplication or data corruption when clients retry requests due to network issues.
What is an Idempotent REST API?
An API that ensures the same request made multiple times has the same impact as making it just once.
What are safe methods in REST APIs?
Methods that do not change server state and are non-intrusive, primarily used for retrieving information.
List examples of safe methods.
If we follow the REST principles in designing our APIs, we will have automatically idempotent REST APIs for GET, PUT, DELETE, HEAD, OPTIONS, and TRACE methods. Only POST and PATCH APIs will not be idempotent.
POST and PATCH are NOT idempotent.
GET, PUT, DELETE, HEAD, OPTIONS and TRACE are idempotent.
- GET
- HEAD
- OPTIONS
- TRACE
What does the GET method do?
Retrieves data from the resource without making any changes to its contents.
What is the purpose of the HEAD method?
Returns only the headers of a resource, used to query metadata without downloading content.
What does the OPTIONS method do?
Gets the supported HTTP verbs for a given URL.
What is the DELETE method used for?
Cancels the resource at the specified URL.
What are idempotent methods?
Methods where performing the same action consecutively produces the same result as only one action.
What does the PUT method do?
Inserts the contents of the request payload into the field of the target URL.
How do idempotency keys work?
They allow non-idempotent methods, like POST, to behave idempotently by identifying and discarding duplicate requests.
What is the function of the POST method?
Used to create resources or perform operations that cannot be considered idempotent.
What is application-level idempotency?
Creating localized code logic within the application to maintain idempotent qualities across different HTTP methods.
Why are idempotent APIs important?
They ensure reliability, consistency, predictability, robustness, simplified client logic, and improved user experience.
What reliability do idempotent APIs provide?
Repeated requests do not cause different responses, aiding stability in distributed systems.
How do idempotent APIs ensure consistency?
They do not alter the state of the server, avoiding undesired impacts on data.
What advantage do idempotent APIs offer developers?
They simplify error correction and minimize bugs in client applications.
What is the benefit of idempotent APIs for user experience?
They guarantee operations complete regardless of network conditions or retries.
What are some idempotent HTTP methods?
2.2. HTTP GET, HEAD, OPTIONS and TRACE
GET, HEAD, OPTIONS and TRACE methods NEVER change the resource state on the server. They are purely for retrieving the resource representation or metadata at that point in time.
So invoking multiple requests will not have any write operation on the server, so GET, HEAD, OPTIONS, and TRACE are idempotent.
2.3. HTTP PUT
Generally – not necessarily – PUT APIs are used to update the resource state. If you execute a PUT API N times, the very first request will update the resource; the other N-1 requests will just overwrite the same resource state again and again – effectively not changing anything.
Hence, PUT is idempotent.
2.4 HTTP DELETE
2.4.1. Delete with the resource identifier
When you execute N similar DELETE requests, the first request will delete the resource and the response will be 200 (OK) or 204 (No Content).
Other N-1 requests will return 404 (Not Found).
Clearly, the response is different from the first request, but there is no change of state for any resource on the server-side because the original resource is already deleted.
So, DELETE is idempotent.
- GET
- PUT
- DELETE
- HEAD
- OPTIONS
- TRACE
What is a consequence of non-idempotent methods?
They can lead to redundancy and negative outcomes if retried without proper handling.
Q: What is the definition of idempotency in API requests?
Generally – not necessarily – POST APIs are used to create a new resource on the server. So when we execute the same POST request N times, we will have N new resources on the server. So, POST is not idempotent.
POST requests can trigger various side effects beyond just resource creation. These side effects may include sending notifications, making changes to the server’s state, or performing actions that are not idempotent.
HTTP PATCH is used for making partial updates to an existing resource without replacing the entire resource. The result of a PATCH request depends on the initial state of the resource and the specific changes provided in the request. Repeating the same PATCH request may lead to different resource states if the resource has been modified in the meantime.
A: 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.
Q: Why is idempotency important for APIs?
In the realm of RESTful web services, idempotency relates to the concept that making the same API request multiple times should yield the same result as making it just once. This means that regardless of how many times you repeat an idempotent request, the outcome remains consistent.
A: Idempotency prevents duplicate operations when users or clients retry requests due to network failures
timeouts
Q: Which common HTTP methods are idempotent by default?
A: GET
PUT
Q: Which common HTTP methods are NOT idempotent by default?
A: POST is not idempotent by default. PATCH depends on implementation.
HTTP Methods and Idempotency
Q: Why is GET considered idempotent?
A: GET is read-only and doesn’t affect the server state
so multiple identical requests have the same effect as a single request.
Q: Why is PUT considered idempotent?
A: No matter how many times we call PUT with the same data
we should always get the same response and the resource will be updated to the same state.
Q: Why is POST typically not idempotent?
Generally – not necessarily – POST APIs are used to create a new resource on the server. So when we execute the same POST request N times, we will have N new resources on the server. So, POST is not idempotent.
POST requests can trigger various side effects beyond just resource creation. These side effects may include sending notifications, making changes to the server’s state, or performing actions that are not idempotent.
HTTP PATCH is used for making partial updates to an existing resource without replacing the entire resource. The result of a PATCH request depends on the initial state of the resource and the specific changes provided in the request. Repeating the same PATCH request may lead to different resource states if the resource has been modified in the meantime.
A: POST typically creates resources
so multiple identical requests would create multiple copies of the same resource or potentially fail after the first succeeds.
Q: When might a DELETE request return different status codes but still be considered idempotent?
A: The first DELETE might return success
while subsequent DELETEs might return errors (resource not found)
Making Non-Idempotent Methods Idempotent
Q: How can you make a POST request idempotent?
A: Add a unique idempotency key in the request header that identifies the specific operation
allowing the server to recognize and handle duplicate requests.
Q: What should an idempotency key be combined with to ensure global uniqueness?
A: The user’s idempotency key should be combined with the user ID and the API path to ensure global uniqueness across users and endpoints.
Q: What is a risk of using just the request body hash as an idempotency key?
A: If the user legitimately wants to make identical requests (like ordering the same product twice)
using just the body hash would prevent the second valid request from being processed.
Implementation Details
Q: Where should idempotency keys be stored?
A: In a distributed key-value storage system like Redis or DynamoDB
not in memory
Q: What is the typical workflow when implementing idempotency?
A: 1) Check if the idempotency key exists in storage; 2) If it exists
return the stored response; 3) If not
Q: How long should idempotency keys typically be stored?
A: Typically between 24 and 48 hours
depending on application needs
Q: What is idempotency validation and when would you use it?
A: Idempotency validation checks if the request body matches the stored hash for a given idempotency key
used to protect against accidental reuse of idempotency keys with different request data.
Implementation in .NET
Q: What libraries can help implement idempotency in .NET Core?
A: The distributed caching library for storing keys in Redis
and the “idempotent-api” NuGet package that handles most of the implementation details.
Q: How can idempotency be applied to specific endpoints in .NET Core?
A: By creating a filter that can be added to the endpoints where idempotency is required.
