Which HTTP method is idempotent by definition, meaning that making the same request multiple times will have the same effect as making it once?
Think about methods that retrieve data without changing server state.
GET is idempotent because it only retrieves data and does not change the server state. Calling GET multiple times returns the same result without side effects.
Consider a REST API where you update a user profile with PUT and create a new user with POST. What is the output of the following sequence of requests?
1. PUT /users/123 with data {"name": "Alice"}
2. PUT /users/123 with data {"name": "Alice"}
3. POST /users with data {"name": "Alice"}Which statement is true about the server state after these requests?
Remember that PUT replaces or creates a resource at a known URL, while POST creates new resources.
PUT is idempotent: calling it multiple times with the same data results in the same server state. POST is not idempotent: each call creates a new resource.
Given this pseudo-code for a REST API endpoint:
def delete_user(user_id):
if user_exists(user_id):
remove_user(user_id)
return "Deleted"
else:
return "User not found"What happens if a client sends the DELETE request twice for the same user_id?
Idempotent methods can be called multiple times without changing the result beyond the initial call.
DELETE is idempotent because deleting a resource once or multiple times results in the resource being gone. The second call returns "User not found" but does not change server state.
Which of the following HTTP request examples correctly uses an idempotent method to update a resource?
PUT replaces the entire resource and is idempotent; PATCH applies partial updates and is not guaranteed idempotent.
PUT is idempotent because sending the same full resource representation multiple times results in the same state. PATCH is not necessarily idempotent because partial updates may accumulate.
You are designing a REST API endpoint to process payment transactions. Which approach ensures the endpoint is idempotent?
Idempotency in payment processing often requires client-generated unique IDs to avoid duplicate charges.
Using POST with a unique transaction ID allows the server to recognize repeated requests and avoid processing duplicates, making the endpoint idempotent.