REST API interview questions: HTTP methods, status codes and resource design
Reviewed by Mark Dickie · Last updated
6 questions on this page you can answer and see marked on the spot. Go to the first one
REST is an architectural style for HTTP APIs in which clients act on resources identified by URIs, using a small set of standard methods. Interviewers usually check whether you can tell the methods apart by safety and idempotency, pick the status code that matches the outcome, and model nested resources without verbs in the URL. A common mistake is calling any JSON-over-HTTP API RESTful, so be ready to say which REST constraints (statelessness, uniform interface, cacheability) an API actually meets.
Which HTTP methods should you know cold for a REST interview?
| Method | Safe | Idempotent | Typical use in a REST API |
|---|---|---|---|
| GET | Yes | Yes | Read a collection or one resource; responses can be cached with ETag |
| PUT | No | Yes | Replace the full resource at a URI the client already knows |
| PATCH | No | Not guaranteed | Partial update, such as changing only the email on a user |
| DELETE | No | Yes | Remove a resource; a repeat call usually returns 404 |
| POST | No | No | Create an item under a collection, or trigger an action such as /orders/{id}/cancel |
How do you work through a REST design question?
- Name the resource before the operation: /orders/{id}/items, not /getOrderItems.
- Return 201 Created with a Location header after a POST that creates something, and 204 No Content after a successful DELETE.
- Explain why a retried PUT is harmless but a retried POST can create a duplicate order, and how an Idempotency-Key header addresses that.
- Use 409 Conflict when the request clashes with current state, and 422 Unprocessable Content when the body fails validation.
- Show which Cache-Control and ETag headers let a GET be served without reaching the origin, and when a 304 Not Modified response applies.
Key facts
- Tarmac has 59 HTTP & APIs interview questions on this topic, 10 of them on this page, at difficulty 2–5 of 5.
- Tarmac tracked 2,889 job postings asking for HTTP & APIs in October 2026.
- Roles asking for HTTP & APIs advertise a median base salary of £77,500, across 671 job postings as of October 2026.
- Tarmac last reviewed these HTTP & APIs interview questions on 9 November 2026.
At a glance
| Questions | 10 shown · 59 in the bank |
|---|---|
| Difficulty | 2–5 of 5 |
| Formats | True / false, Fill in the blank, Flashcard, Multiple choice, Find the bug, Ordering, Multiple answer, Short answer |
What you'll review
- rest principles
- resource design
- idempotency
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
True or false: In REST, statelessness means the server must not store any client session state between requests, and each client request must contain all the information the server needs to understand and process it.#
Options
Show answer
True. Statelessness is a core REST constraint: the server stores no client session state between requests, so every request must carry all the information needed to process it. Because any server instance can handle any request, this design improves scalability and reliability.
Statelessness is one of the architectural constraints Roy Fielding defined for REST. The server handles each request independently, without relying on session or application state stored from earlier requests, so each request must be self-describing. This improves scalability and reliability because any server instance can handle any request.
In REST, the HTTP methods GET, PUT, and DELETE are _____, meaning that issuing the same request multiple times produces the same effect as issuing it once. The POST method is not — each call may create a new resource or trigger a distinct side effect.#
Show answer
In REST, the HTTP methods GET, PUT, and DELETE are idempotent, meaning that issuing the same request multiple times produces the same effect as issuing it once. The POST method is not — each call may create a new resource or trigger a distinct side effect.
Idempotency is a key property in REST. GET, PUT, and DELETE are idempotent HTTP methods: repeated identical calls have the same effect as a single call. POST is intentionally not idempotent because it is used to create new resources or trigger non-repeatable actions, so each call can produce a distinct result.
In REST, the uniform interface constraint includes four sub-constraints. One of them is HATEOAS (Hypermedia As The Engine Of Application State). Briefly describe what HATEOAS means and give a concrete example.#
Show answer
HATEOAS means that REST responses embed hypermedia links the client can follow to discover the next valid actions, rather than the client hard-coding URIs — the hypermedia in the response drives the application state transitions. For example, a GET /orders/123 response might include a _links object with rel: 'payment' → /orders/123/payment and rel: 'cancel' → /orders/123/cancel; the client reads these links dynamically and follows them without knowing the URL structure in advance.
The back directly describes HATEOAS — responses carry hypermedia links that tell the client what actions are available next, so the client need not hard-code URI patterns — and then gives a concrete example: a GET /orders/123 response whose _links object exposes payment and cancel relation links the client follows dynamically. This matches the prompt's two explicit requirements: a brief description and a concrete example.
What does the statelessness constraint of REST require?#
Options
Show answer
Statelessness requires that each request contains all the information needed to process it, with the server keeping no client session state between requests. Because every request is self-contained (carrying its own auth token, for example), any server instance can handle any request, which makes horizontal scaling and load balancing straightforward. It says nothing about persistent application data, which servers do store.
Statelessness means no client session context is stored on the server between requests — each request is self-contained (e.g. carries its own auth token), which is what lets any server instance handle any request and makes horizontal scaling and load balancing straightforward. It says nothing about persistent application data, which servers absolutely do store.
These routes are meant to follow RESTful resource-design conventions. Which line breaks them?#
router.get("/users", listUsers);
router.get("/users/:id", getUser);
router.post("/createUser", createUser);
router.delete("/users/:id", deleteUser);Show answer
The bug is on line 3.
REST URLs should name resources (nouns), with the HTTP method supplying the verb. POST /createUser puts the action in the URL; it should be POST /users — the POST already conveys "create", and the collection resource is /users. The other three correctly use the noun /users with GET/DELETE carrying the intent.
Order what happens when a browser makes a request to https://api.example.com/users, from typing the URL to rendering the data.#
Put these in order
Show answer
The request lifecycle runs in this order:
- Resolve
api.example.comto an IP address via DNS. - Open a TCP connection to that IP on port 443.
- Perform the TLS handshake to establish an encrypted channel.
- Send the HTTP request line and headers over the connection.
- The server routes, authorizes, and processes the request.
- Receive the HTTP status, headers, and body, then parse the data.
Each layer builds on the one before: name resolution, then a transport connection, then TLS over that connection, and only then the HTTP exchange. REST's stateless, layered design means the server processes each self-contained request independently and any number of intermediaries (proxies, load balancers, caches) can sit transparently between client and origin.
An API requires an Idempotency-Key header on POST /payments. A client sends a charge, the server commits it successfully, but the 200 response is lost to a network timeout. The client retries with the same Idempotency-Key. What should a correctly-implemented server do?#
Options
Show answer
The server should recognise the stored key and return the exact same response it produced the first time, without charging the card again. An idempotency key makes an unsafe POST safe to retry: the server records the key alongside its response, then replays that stored response verbatim on any later request bearing the same key. So the timed-out retry gets the original 200 and the card is charged once.
The whole point of an idempotency key is to make an unsafe operation (POST of a charge) safe to retry: the server records the key together with the response it produced, and a later request bearing the same key replays that stored response verbatim instead of re-executing the side effect. So the timed-out retry gets the original 200 and the card is charged once. The option that describes plain stateless HTTP defeats the mechanism — it would double-charge. The option that says a repeated key is a malformed, duplicate request is wrong because a repeated key is exactly the expected, supported case, not a client error. The option that says to respond 409 Conflict is the tempting trap: 409 Conflict is the right answer only for the different scenario where a second request with the same key arrives while the first is still in flight — the server locks on the key and rejects the concurrent duplicate. For a replay of an already-completed request there is nothing in conflict; the server simply returns the cached original result.
Which HTTP methods are idempotent — making the identical request many times leaves the server in the same state as making it once?#
Options
Pick every one that applies.
Show answer
GET, PUT, and DELETE are idempotent — but not POST. Repeating PUT re-sets the same state, and repeating DELETE leaves the resource deleted (later calls may return 404, but the server state is unchanged). POST is not idempotent because each call typically creates a new resource, which is why retries need an idempotency key.
GET, PUT, and DELETE are idempotent: repeating PUT re-sets the same state, and repeating DELETE leaves the resource deleted (the later calls may return 404, but the server state is unchanged). POST is not idempotent — each call typically creates a new resource, which is why retries need an idempotency key (RFC 9110 §9.2.2).
What does it mean for an HTTP method to be idempotent, and why does it matter for clients that retry?#
Show answer
An idempotent method produces the same server state whether the identical request is sent once or many times. PUT and DELETE are idempotent (and GET is too); POST is not. It matters because a client that times out can safely retry an idempotent request without risk of duplicating the effect — repeating a DELETE still leaves the resource gone, whereas blindly retrying a POST could create duplicates, which is why non-idempotent writes use an idempotency key.
Idempotency is about the effect on server state, not the response body: repeating an idempotent request leaves the same state as a single call (RFC 9110 §9.2.2). Safe methods are a subset — all safe methods are idempotent. This property is what makes automatic retries of GET/PUT/DELETE safe, while POST retries need an idempotency key to avoid duplicate side effects.
A REST API implements these endpoints (RFC 9110 semantics assumed throughout):<br><br>• <code>GET /widgets/{id}</code> — returns the widget or 404.<br>• <code>PUT /widgets/{id}</code> — creates or replaces the widget with the request body; returns 201 on first create, 200 on subsequent replace.<br>• <code>DELETE /widgets/{id}</code> — deletes the widget; returns 200 if it existed, 404 if not.<br>• <code>POST /widgets/{id}/views</code> — increments a view counter; returns 200.<br>• <code>POST /widgets</code> — creates a new widget with a server-generated id; returns 201.<br><br>Regarding HTTP idempotency as defined by RFC 9110, which of the following statements are TRUE?#
Options
Pick every one that applies.
Show answer
Three statements hold: DELETE and PUT are idempotent because RFC 9110 defines idempotency as identical server state after one or more identical requests — not identical responses — so different status codes (200→404, 201→200) conform. POST …/views is non-idempotent since the counter changes per call. The other two fail: GET safety doesn't bar all server side effects (the RFC acknowledges logging), and POST has no protocol-level deduplication requirement on retry.
RFC 9110 defines idempotency as a property of server state — identical requests, whether issued once or N times, leave the server in the same state — not as identical responses. DELETE and PUT are idempotent methods: after two identical DELETE calls the resource is gone just as it was after the first, and after two identical PUT calls with the same body the resource content is the same as after one. The differing status codes (200→404 for DELETE, 201→200 for PUT) are fully conformant because the RFC states that idempotent requests 'might not have the same response.' POST /widgets/{id}/views is non-idempotent: each call mutates the counter, so the server state after two calls differs from after one. The GET statement is false because the RFC explicitly acknowledges that 'it is not possible to ensure that the server does not generate side effects while handling a request' — safety concerns the requested semantics (read-only intent), not a prohibition on all server-side side effects. The POST /widgets statement is false because POST is not idempotent per the spec; there is no protocol-level requirement to deduplicate or return the same resource id on retry — preventing duplicates is an application-level concern typically handled with an Idempotency-Key header or a uniqueness constraint.
Sources
The official documentation these questions are checked against:
Related interview questions
Job market
See http-apis salaries and hiring demand from live job postings.
The other 49 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 49 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 answers per 30 days, each marked with written feedback