REST APIs map each action on a resource to one of the HTTP methods.
GET retrieves data from the server. It should be safe and idempotent.
POST creates new resources or submits data for processing.
PUT updates an entire resource, or creates it if it doesn't exist. It should be idempotent.
PATCH partially updates a resource.
DELETE removes a resource. It should be idempotent.
HEAD works like GET but returns only headers, not the body.
OPTIONS returns the methods allowed for a resource.
Here they are applied to one user resource.
GET /users/123 # Retrieve user with ID 123
POST /users # Create a new user
PUT /users/123 # Update entire user 123
PATCH /users/123 # Partially update user 123
DELETE /users/123 # Delete user 123
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
Which of these methods are idempotent, and why does that matter in practice?GET, HEAD, OPTIONS, PUT and DELETE are idempotent. POST is not, and PATCH only if designed so. Tie it to safe retries after a timeout.
When would you pick PATCH over PUT?PUT sends the full resource and replaces it. PATCH sends only the changed fields, as JSON Merge Patch or JSON Patch, and isn't idempotent by default.
What's the difference between a safe method and an idempotent one?Safe means the request asks for no state change. Idempotent means repeating it has the same effect as once. PUT and DELETE are idempotent but not safe.
A client's POST to create an order times out and it retries. How do you avoid a duplicate order?Use an idempotency key. The client sends a unique key, and the server stores the first result and returns it for repeats instead of creating a second order.
What status codes would you return from a successful POST, PUT and DELETE?201 Created with a Location header for POST, 200 or 204 for PUT and DELETE. Also say what a repeat DELETE returns, 404 or 204.
What you can say
The HTTP method tells the server what action to take and the URL names the resource, so GET /users/123 and DELETE /users/123 hit the same user but do different things.
GET reads a resource without changing it, and HEAD is the same request but returns only the headers.
POST creates a new resource, like POST /users, or submits data for the server to process.
PUT replaces the whole resource, or creates it if it doesn't exist, while PATCH updates only the fields you send.
DELETE removes the resource, and OPTIONS tells the client which methods that resource allows.
The thing I'd stress is idempotency, since GET, PUT and DELETE give the same result if repeated but POST doesn't, so a blind retry of a POST can create a duplicate.
Weak answers to avoid
Recites the list, never mentions idempotencyThe verbs are the easy part. Say which methods are safe and idempotent, because that decides what a client can retry and what a cache can store.
Treats PUT and PATCH as the same thingPUT replaces the whole resource, so a field you leave out can be reset or lost. PATCH changes only what you send. Mixing them up loses data.
Uses GET for requests that change dataGET must be safe. Crawlers, link prefetchers and caches call GET freely, so GET /users/123/delete can wipe data. Use POST, PUT, PATCH or DELETE.
Calls POST idempotent, or PATCH always idempotentTwo identical POSTs can create two resources. PATCH depends on the patch, since 'add 1 to count' changes the result each time. Getting this wrong leads to unsafe retries.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
