REST uses standard HTTP methods as the verbs that act on resources. The common mapping to CRUD (Create, Read, Update, Delete) is:
REST uses standard HTTP methods as the verbs that act on resources. The common mapping to CRUD (Create, Read, Update, Delete) is:
| CRUD | Method | Typical use |
|---|
| Create | POST | Add a new resource to a collection |
| Read | GET | Fetch a resource or list |
| Update (full) | PUT | Replace a resource entirely |
| Update (partial) | PATCH | Modify some fields |
| Delete | DELETE | Remove a resource |
POST /users HTTP/1.1
Content-Type: application/json
{ "name": "Ann", "email": "[email protected]" }
HTTP/1.1 201 Created
Location: /users/42
{ "id": 42, "name": "Ann", "email": "[email protected]" }
PUT /users/42 sends the whole representation and replaces it; PATCH /users/42 sends only the fields to change (e.g. { "email": "[email protected]" }).
These are two different properties:
GET, HEAD, OPTIONS are safe.GET, PUT, DELETE, HEAD are idempotent.Method Safe? Idempotent?
GET yes yes
HEAD yes yes
PUT no yes (replacing with the same body twice = same result)
DELETE no yes (deleting twice = still deleted)
PATCH no no* (depends on the patch; not guaranteed)
POST no no (posting twice usually creates two resources)
Interviewers ask this to see whether you understand HTTP semantics well enough to build reliable APIs. The safe/idempotent distinction is not academic: it directly governs what clients, proxies, and CDNs are allowed to do. Safe methods can be cached and prefetched freely; idempotent methods can be automatically retried after a network timeout without risk of duplicating side effects — which is why a client can safely retry a PUT or DELETE but must be careful retrying a POST (it might create two orders). The classic mistake is using GET to trigger side effects (e.g. GET /users/42/delete), which breaks caching and lets crawlers accidentally mutate data. Choosing the right method — and respecting its safety and idempotency contract — is what makes an API predictable and safe to build tooling around.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate