2.3 Idempotency

Question 1

What is idempotency?

Answer 1

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.

Question 2

How does idempotency apply to APIs?

Answer 2

A client can send the same request multiple times without causing unintended consequences, such as duplicate entries or repeated side effects.

Question 3

What happens if a user experiences a timeout during an online payment API call?

Answer 3

The payment API is called again as part of the retry mechanism, potentially leading to multiple charges without idempotency.

Question 4

What is the impact of idempotency on user account registrations?

Answer 4

Without idempotency, duplicate user accounts might be created if the registration form is submitted multiple times.

Question 5

Why is idempotency critical for reliability and consistency?

Answer 5

It prevents undesired duplication or data corruption when clients retry requests due to network issues.

Question 6

What is an Idempotent REST API?

Answer 6

An API that ensures the same request made multiple times has the same impact as making it just once.

Question 7

What are safe methods in REST APIs?

Answer 7

Methods that do not change server state and are non-intrusive, primarily used for retrieving information.

Question 8

List examples of safe methods.

Answer 8

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

Question 9

What does the GET method do?

Answer 9

Retrieves data from the resource without making any changes to its contents.

Question 10

What is the purpose of the HEAD method?

Answer 10

Returns only the headers of a resource, used to query metadata without downloading content.

Question 11

What does the OPTIONS method do?

Answer 11

Gets the supported HTTP verbs for a given URL.

Question 12

What is the DELETE method used for?

Answer 12

Cancels the resource at the specified URL.

Question 13

What are idempotent methods?

Answer 13

Methods where performing the same action consecutively produces the same result as only one action.

Question 14

What does the PUT method do?

Answer 14

Inserts the contents of the request payload into the field of the target URL.

Question 15

How do idempotency keys work?

Answer 15

They allow non-idempotent methods, like POST, to behave idempotently by identifying and discarding duplicate requests.

Question 16

What is the function of the POST method?

Answer 16

Used to create resources or perform operations that cannot be considered idempotent.

Question 17

What is application-level idempotency?

Answer 17

Creating localized code logic within the application to maintain idempotent qualities across different HTTP methods.

Question 18

Why are idempotent APIs important?

Answer 18

They ensure reliability, consistency, predictability, robustness, simplified client logic, and improved user experience.

Question 19

What reliability do idempotent APIs provide?

Answer 19

Repeated requests do not cause different responses, aiding stability in distributed systems.

Question 20

How do idempotent APIs ensure consistency?

Answer 20

They do not alter the state of the server, avoiding undesired impacts on data.

Question 21

What advantage do idempotent APIs offer developers?

Answer 21

They simplify error correction and minimize bugs in client applications.

Question 22

What is the benefit of idempotent APIs for user experience?

Answer 22

They guarantee operations complete regardless of network conditions or retries.

Question 23

What are some idempotent HTTP methods?

Answer 23

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

Question 24

What is a consequence of non-idempotent methods?

Answer 24

They can lead to redundancy and negative outcomes if retried without proper handling.

Question 25

Q: What is the definition of idempotency in API requests?

Answer 25

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.

Question 26

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.

Question 27

Q: Why is idempotency important for APIs?

Answer 27

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.

Question 28

A: Idempotency prevents duplicate operations when users or clients retry requests due to network failures

Answer 28

timeouts

Question 29

Q: Which common HTTP methods are idempotent by default?

Question 30

A: GET

Answer 30

PUT

Question 31

Q: Which common HTTP methods are NOT idempotent by default?

Question 32

A: POST is not idempotent by default. PATCH depends on implementation.

Question 33

HTTP Methods and Idempotency

Question 34

Q: Why is GET considered idempotent?

Question 35

A: GET is read-only and doesn't affect the server state

Answer 35

so multiple identical requests have the same effect as a single request.

Question 36

Q: Why is PUT considered idempotent?

Question 37

A: No matter how many times we call PUT with the same data

Answer 37

we should always get the same response and the resource will be updated to the same state.

Question 38

Q: Why is POST typically not idempotent?

Answer 38

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.

Question 39

A: POST typically creates resources

Answer 39

so multiple identical requests would create multiple copies of the same resource or potentially fail after the first succeeds.

Question 40

Q: When might a DELETE request return different status codes but still be considered idempotent?

Question 41

A: The first DELETE might return success

Answer 41

while subsequent DELETEs might return errors (resource not found)

Question 42

Making Non-Idempotent Methods Idempotent

Question 43

Q: How can you make a POST request idempotent?

Question 44

A: Add a unique idempotency key in the request header that identifies the specific operation

Answer 44

allowing the server to recognize and handle duplicate requests.

Question 45

Q: What should an idempotency key be combined with to ensure global uniqueness?

Question 46

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.

Question 47

Q: What is a risk of using just the request body hash as an idempotency key?

Question 48

A: If the user legitimately wants to make identical requests (like ordering the same product twice)

Answer 48

using just the body hash would prevent the second valid request from being processed.

Question 49

Implementation Details

Question 50

Q: Where should idempotency keys be stored?

Question 51

A: In a distributed key-value storage system like Redis or DynamoDB

Answer 51

not in memory

Question 52

Q: What is the typical workflow when implementing idempotency?

Question 53

A: 1) Check if the idempotency key exists in storage; 2) If it exists

Answer 53

return the stored response; 3) If not

Question 54

Q: How long should idempotency keys typically be stored?

Question 55

A: Typically between 24 and 48 hours

Answer 55

depending on application needs

Question 56

Q: What is idempotency validation and when would you use it?

Question 57

A: Idempotency validation checks if the request body matches the stored hash for a given idempotency key

Answer 57

used to protect against accidental reuse of idempotency keys with different request data.

Question 58

Implementation in .NET

Question 59

Q: What libraries can help implement idempotency in .NET Core?

Question 60

A: The distributed caching library for storing keys in Redis

Answer 60

and the "idempotent-api" NuGet package that handles most of the implementation details.

Question 61

Q: How can idempotency be applied to specific endpoints in .NET Core?

Question 62

A: By creating a filter that can be added to the endpoints where idempotency is required.