HTTP methods state your intent on a resource; status codes are the server's coded answer. Two properties matter for methods: safe (read-only, no side effects) and idempotent (repeating it yields the same result — important for safe retries).
HTTP methods state your intent on a resource; status codes are the server's coded answer. Two properties matter for methods: safe (read-only, no side effects) and idempotent (repeating it yields the same result — important for safe retries).
| Method | Purpose | Safe | Idempotent |
|---|
| GET | Read a resource | Yes | Yes |
| POST | Create / trigger an action | No | No |
| PUT | Replace a resource | No | Yes |
| PATCH | Partially update | No | No* |
| DELETE | Remove a resource | No | Yes |
| HEAD | Like GET, headers only | Yes | Yes |
The idempotency distinction is practical: because PUT and DELETE are idempotent, a client can safely retry them after a timeout; retrying a non-idempotent POST risks creating a duplicate (a classic double-charge bug).
Status codes are grouped by their first digit:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
The most important line is the 4xx vs 5xx split: 4xx means the client sent something wrong (bad input, not authenticated, not found) — retrying unchanged won't help; 5xx means the server failed — retrying (with backoff) might succeed. Know the everyday ones cold: 401 (not authenticated) vs 403 (authenticated but not allowed), 404 (not found), 429 (rate limited), 500 (generic server crash), 502/503/504 (bad gateway / unavailable / gateway timeout — usually an upstream or overload problem).
These codes are the shared contract between every client and server, so fluency here is expected of anyone building or consuming APIs. Interviewers probe the distinctions that reveal real understanding: 401 vs 403, PUT vs PATCH, and especially idempotency, which directly governs whether retries are safe — a core concern in distributed systems and payment flows. Returning the right status code also makes your API predictable and correctly handled by caches, proxies, and client libraries, so this knowledge shapes good API design, not just trivia.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate