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.