Idempotency of methods in Rest API - Step-by-Step Execution

Concept Flow - Idempotency of methods

Client sends request

↓

Server receives request

↓

Check method type

↓

Read

↓

Return response

↓

Client receives response

This flow shows how REST API methods behave, focusing on idempotent methods that produce the same effect even if called multiple times.

Execution Sample

Rest API

PUT /user/123 {"name": "Alice"}
PUT /user/123 {"name": "Alice"}
GET /user/123
POST /user
POST /user

This example shows repeated PUT requests with same data (idempotent) and POST requests (non-idempotent).

Execution Table

Step	HTTP Method	Request Data	Server Action	Effect on Server State	Response	Idempotent?
1	PUT	{"name": "Alice"}	Update user 123 name to Alice	User 123 name set to Alice	200 OK	Yes
2	PUT	{"name": "Alice"}	Update user 123 name to Alice	User 123 name remains Alice	200 OK	Yes
3	GET	N/A	Retrieve user 123 data	No change	200 OK with user data	Yes
4	POST	{"name": "Bob"}	Create new user with name Bob	New user created with new ID	201 Created	No
5	POST	{"name": "Bob"}	Create new user with name Bob	Another new user created with new ID	201 Created	No
6	DELETE	N/A	Delete user 123	User 123 removed	204 No Content	Yes
7	DELETE	N/A	Delete user 123	User 123 already deleted, no change	204 No Content	Yes

💡 Execution stops after demonstrating repeated calls and their effects on server state.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 5	After Step 6	After Step 7
User 123 name	Unknown	Alice	Alice	Alice	Alice	Deleted	Deleted
User count	0	0	0	1	2	2	2

Key Moments - 3 Insights

Why does sending the same PUT request twice not create two users?

Because PUT is idempotent, it updates the same resource each time without creating new ones, as shown in steps 1 and 2 where user 123's name stays 'Alice'.

Why do two POST requests with the same data create two different users?

POST is not idempotent; each call creates a new resource, so steps 4 and 5 show two new users created with different IDs.

Is DELETE idempotent if the resource is already deleted?

Yes, DELETE is idempotent because deleting an already deleted resource has no further effect, as shown in steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution table, what is the server state of user 123 after step 2?

A User 123 name is Alice

B User 123 is deleted

C User 123 name is unknown

D User 123 name is Bob

💡 Hint

Check the 'Effect on Server State' column for step 2 in the execution table.

At which step does the server create a new user for the first time?

A Step 2

B Step 4

C Step 1

D Step 6

💡 Hint

Look for 'Create new user' in the 'Server Action' column.

If the DELETE method was not idempotent, what would happen at step 7?

A It would create a new user

B It would return an error or change state

C It would do nothing

D It would update user 123's name

💡 Hint

Consider the 'Effect on Server State' and 'Idempotent?' columns for DELETE steps.

Concept Snapshot

Idempotency means repeating the same request has the same effect as doing it once.
GET, PUT, DELETE are idempotent methods.
POST is not idempotent because it creates new resources each time.
Idempotent methods help avoid unintended changes on retries.
Use idempotency to make APIs reliable and safe.

Full Transcript

This lesson shows how REST API methods behave with respect to idempotency. We trace repeated calls to PUT, POST, GET, and DELETE. PUT updates the same resource without creating duplicates, so calling it twice with the same data keeps the state unchanged. POST creates new resources each time, so repeated POST calls add multiple users. DELETE removes a resource and is idempotent because deleting an already deleted resource does nothing. The execution table tracks each step's method, action, server state, and response. Variable tracking shows user data and count changes. Key moments clarify common confusions about why PUT is idempotent but POST is not, and how DELETE behaves. The visual quiz tests understanding of server state after repeated calls. The snapshot summarizes idempotency rules for REST methods.

Practice

1. Which HTTP method is idempotent, meaning it can be called multiple times without changing the result beyond the initial application?

easy

A. POST

B. CONNECT

C. PUT

D. PATCH

Solution

1. Step 1: Understand idempotency in HTTP methods

   Idempotent methods produce the same result no matter how many times they are called with the same input.

2. Step 2: Identify which methods are idempotent

   GET, PUT, and DELETE are idempotent. POST and PATCH are not because they can create or modify resources differently each time.

3. Final Answer:

   PUT -> Option C

4. Quick Check:

   PUT is idempotent = B [OK]

Hint: Remember: PUT replaces, POST creates new [OK]

Common Mistakes:

• Confusing POST as idempotent
• Thinking PATCH is idempotent
• Assuming CONNECT is idempotent

2. Which of the following is the correct syntax to perform an idempotent DELETE request using curl?

easy

A. curl -X DELETE https://api.example.com/resource/123

B. curl -X POST https://api.example.com/resource/123

C. curl -X PUT https://api.example.com/resource/123

D. curl -X GET https://api.example.com/resource/123

Solution

1. Step 1: Identify the HTTP method for deletion

   DELETE is the HTTP method used to remove a resource and is idempotent.

2. Step 2: Check curl syntax for DELETE

   The correct curl command uses -X DELETE followed by the resource URL.

3. Final Answer:

   curl -X DELETE https://api.example.com/resource/123 -> Option A

4. Quick Check:

   DELETE method syntax = C [OK]

Hint: DELETE uses -X DELETE in curl command [OK]

Common Mistakes:

• Using POST instead of DELETE
• Omitting -X flag for method
• Confusing GET with DELETE

3. Consider this sequence of HTTP requests to update a user's email:

PUT /users/42 {"email": "[e-mail]"}
PUT /users/42 {"email": "[e-mail]"}

What is the expected result after these two requests?

medium

A. User's email remains unchanged after the first update

B. User's email is updated once and remains the same after second request

C. User's email is updated twice, causing duplicate entries

D. An error occurs on the second request

Solution

1. Step 1: Understand PUT idempotency

   PUT replaces the resource with the given data. Multiple identical PUT requests do not change the resource after the first update.

2. Step 2: Analyze the two identical PUT requests

   The first request updates the email. The second request sends the same data, so no further change occurs.

3. Final Answer:

   User's email is updated once and remains the same after second request -> Option B

4. Quick Check:

   PUT idempotent means same result = A [OK]

Hint: PUT with same data does not change resource again [OK]

Common Mistakes:

• Assuming PUT creates duplicates
• Thinking second PUT causes error
• Confusing PUT with POST behavior

4. A developer wrote this code snippet to delete a resource:

fetch('https://api.example.com/items/10', { method: 'POST' })
  .then(response => console.log('Deleted'));

Why is this code incorrect for an idempotent delete operation?

medium

A. The response is not handled properly

B. The URL is missing a query parameter

C. The fetch method is missing headers

D. POST is not idempotent and should not be used for deletion

Solution

1. Step 1: Identify the HTTP method used

   The code uses POST to delete a resource, which is incorrect because POST is not idempotent.

2. Step 2: Understand correct method for deletion

   DELETE method should be used for idempotent deletion, ensuring repeated calls do not cause unintended effects.

3. Final Answer:

   POST is not idempotent and should not be used for deletion -> Option D

4. Quick Check:

   DELETE is idempotent, POST is not = A [OK]

Hint: Use DELETE, not POST, for idempotent deletes [OK]

Common Mistakes:

• Using POST for delete operations
• Ignoring HTTP method semantics
• Assuming POST is idempotent

5. You want to design an API endpoint to update user profile data safely. Which approach ensures idempotency and avoids duplicate updates if the client retries the request multiple times?

hard

A. Use PUT method to update the entire user profile with the same data each time

B. Use GET method with query parameters to update user data

C. Use PATCH method to partially update user data without tracking changes

D. Use POST method to update user data with a unique request ID

Solution

1. Step 1: Understand idempotent update methods

   PUT replaces the entire resource and is idempotent, so repeated calls with the same data do not cause duplicate changes.

2. Step 2: Evaluate options for safe updates

   POST is not idempotent, PATCH is not guaranteed idempotent, GET should not modify data. PUT is the best choice for safe, repeatable updates.

3. Final Answer:

   Use PUT method to update the entire user profile with the same data each time -> Option A

4. Quick Check:

   PUT ensures idempotent updates = D [OK]

Hint: PUT replaces resource fully, safe for retries [OK]

Common Mistakes:

• Using POST for updates expecting idempotency
• Assuming PATCH is always idempotent
• Trying to update data with GET