What are the common HTTP methods and status codes, and what does idempotent mean?
GET reads, POST creates or triggers an action, PUT replaces, PATCH partly updates and DELETE removes. A method is idempotent if repeating the same request leaves the server in the same state as doing it once - GET, PUT and DELETE are, POST is not. Status codes are grouped as 2xx success, 3xx redirect, 4xx client error and 5xx server error.
Explain it simply
Think of a lift. Pressing the button for floor 5 once or ten times has the same result: the lift goes to floor 5. That is idempotent. Now think of ordering on a food app: tapping "Place order" three times can give you three biryanis and three charges. That is not idempotent.
HTTP methods are verbs that tell the server what you want to do with a resource, and status codes are the server's short reply about how it went.
Example
| Method | Meaning | Safe (read-only)? | Idempotent? | Example |
|---|---|---|---|---|
| GET | Read a resource | Yes | Yes | GET /users/42 |
| POST | Create, or run an action | No | No | POST /orders |
| PUT | Replace a resource completely | No | Yes | PUT /users/42 with the full user |
| PATCH | Update part of a resource | No | Not guaranteed | PATCH /users/42 with {"city": "Pune"} |
| DELETE | Remove a resource | No | Yes | DELETE /users/42 |
| HEAD | Like GET, headers only | Yes | Yes | Check if a file changed |
| OPTIONS | Ask what is allowed | Yes | Yes | CORS preflight |
Status codes you should know:
| Code | Meaning | When you see it |
|---|---|---|
| 200 OK | Success | A normal GET |
| 201 Created | Resource created | After a POST that made something |
| 204 No Content | Success, nothing to return | After a DELETE |
| 301 / 308 | Moved permanently | Old URL redirected forever |
| 302 / 307 | Temporary redirect | Redirect to the login page |
| 304 Not Modified | Use your cached copy | Conditional GET with If-None-Match |
| 400 Bad Request | Malformed input | Invalid JSON |
| 401 Unauthorized | Not logged in, or bad credentials | Missing or expired token |
| 403 Forbidden | Logged in but not allowed | A student opening the admin page |
| 404 Not Found | No such resource | Wrong URL |
| 409 Conflict | Clashes with current state | Username already taken |
| 429 Too Many Requests | Rate limited | Too many OTP requests |
| 500 Internal Server Error | Bug on the server | Unhandled exception |
| 502 Bad Gateway | Proxy got a bad reply from upstream | App server crashed behind Nginx |
| 503 Service Unavailable | Overloaded or in maintenance | Rush when a big sale opens |
| 504 Gateway Timeout | Upstream took too long | Slow database query behind a proxy |
How it works
Safe means the request should not change anything on the server. Idempotent means sending the same request many times has the same effect on the server as sending it once. The response can differ: the first DELETE /users/42 may return 204 and the second 404, but the user is gone either way, so DELETE is still idempotent.
PUT is idempotent because it sets the whole resource to the given value; setting it twice gives the same result. POST usually creates something new each time. PATCH depends on the change: {"city": "Pune"} is idempotent in effect, but "add 100 to balance" is not.
Idempotency matters because networks fail. If a request times out, the client does not know whether the server processed it. Browsers, proxies and HTTP client libraries can safely retry idempotent methods, but blindly retrying a POST can create duplicates.
Real-world use
Payment APIs solve the "did my payment go through?" problem with an idempotency key: the client sends a unique ID in a header with the POST, and if the same key arrives again, the server returns the original result instead of charging twice. Good REST APIs return precise codes, such as 201 with a Location header after creation, or 429 with a Retry-After header, so clients can react correctly.
Common mistakes
- Using GET for actions that change data, like
GET /deleteUser?id=42. Crawlers and link previews can trigger it. - Mixing up 401 and 403. 401 is "who are you?"; 403 is "I know who you are, and no".
- Returning 200 with
{"error": "..."}in the body. Clients and monitoring tools rely on the status code. - Saying idempotent means "returns the same response". It is about the server's state.
- Treating PUT and PATCH as the same thing.
What to say in the interview
"GET reads data, POST creates a resource or triggers an action, PUT replaces a resource, PATCH partially updates it and DELETE removes it. GET, HEAD and OPTIONS are safe, meaning they do not change state. Idempotent means repeating the request leaves the server in the same state as one call; GET, PUT and DELETE are idempotent, POST is not, and PATCH depends on the operation. This matters for retries after timeouts, which is why payment APIs use idempotency keys on POST. For status codes: 2xx success, 3xx redirection, 4xx client errors like 400, 401, 403 and 404, and 5xx server errors like 500, 502, 503 and 504."
Follow-up questions
- Why is DELETE idempotent if the second call returns 404?
- How would you make a POST endpoint safe to retry?
- What is the difference between 301 and 302, and between 302 and 307?
- When does a browser send an OPTIONS request?
Go deeper
Read these once the basics above feel easy.
307 and 308 were added because many clients changed a POST into a GET when following 301 and 302. With 307 and 308 the method and body must be kept. For caching, the server sends an ETag; the browser later sends it back in If-None-Match, and the server answers 304 with no body if nothing changed, saving bandwidth.