REST = REpresentational State Transfer. Instead of inventing a custom function for everything (getUser, deleteUserById, updateUserEmail...), REST says:
Model your domain as resources (a user, an order, a comment).
Each resource has a stable URI (address), e.g. /users/42.
You transfer representations of that resource's state (JSON, usually) back and forth.
The verb (what you want to do) lives in the HTTP method, not the URL.
What does REST stand for and what's its core idea?
Representational State Transfer — model the domain as resources (nouns) addressed by URIs, acted on by a small fixed set of HTTP methods (verbs), transferring state representations (JSON).
Where does the verb go in a RESTful URL, e.g. delete user 42?
In the HTTP method (DELETE /users/42), NOT the URL. URLs name resources, never actions like /deleteUser.
Define "safe" vs "idempotent" HTTP methods.
Safe = no server-state change (GET). Idempotent = N calls give same final state as 1 call (GET, PUT, DELETE). POST is neither.
Why is POST not idempotent and why does that matter for retries?
Each POST creates a new resource, so retrying after a timeout may create duplicates (e.g. double charge). PUT/DELETE to a known id are safe to retry.
Difference between PUT and PATCH?
PUT = full replace (omitted fields are wiped/defaulted); PATCH = partial merge (omitted fields unchanged).
What status code for a successful POST that created a resource, and what header?
201 Created, with a Location: header giving the new resource's URI.
What status code for a successful DELETE with no body?
204 No Content.
Difference between 401 and 403?
401 = not authenticated (who are you? log in / send token). 403 = authenticated but not permitted.
What do the first digits 2xx/3xx/4xx/5xx mean?
2xx success, 3xx redirect, 4xx client error, 5xx server error.
When use 409 Conflict?
Request clashes with current state — e.g. duplicate unique field, edit version mismatch.
Name three API versioning strategies.
URI (/v1/users), header (Accept: vnd.app.v2+json), query param (?version=2).
What is a breaking vs non-breaking API change?
Breaking: remove/rename field, change type, make optional required. Non-breaking (additive): new optional field or new endpoint.
Offset formula for 1-indexed page p with page size L?
offset = (p-1)*L.
Total pages for N items, page size L, and why ceiling?
ceil(N/L); the final partial page of leftover rows still needs its own page.
Offset vs cursor pagination — key tradeoff?
Offset: can jump to any page but unstable on live data + slow at deep offsets. Cursor (keyset): stable & fast (WHERE key > cursor) but can't jump to arbitrary page.
Recall Feynman: explain to a 12-year-old
Imagine a giant library. Every book has its own shelf address (that's the URL). You don't shout custom orders like "GoFetchBook37" — you use a few standard actions: read it (GET), add a new one (POST), swap it for a new copy (PUT), fix a page (PATCH), or throw it out (DELETE). When you ask, the librarian holds up a colored card: green = done (2xx), yellow = you messed up your request (4xx), red = librarian tripped (5xx). The library is huge, so they hand you books 20 at a time (pagination). And when they redesign the catalog, they keep the old catalog (v1) open so people who learned it don't get lost.
REST API ka core idea simple hai: apne system ki cheezein (jaise user, order, comment) ko resources banao, aur har resource ko ek address (URL) do — jaise /users/42. Ab kaam karne ke liye naya-naya function nahi banate; bas HTTP ke fixed verbs use karte ho: GET (padho), POST (naya banao), PUT (poora replace), PATCH (thoda update), DELETE (hatao). Yaad rakho — URL me noun hota hai, action (verb) method me jaata hai. /deleteUser galat hai, DELETE /users/42 sahi hai.
Server jawab me ek status code bhejta hai jo machine ko batata hai kya hua: 2xx matlab success (201 = ban gaya, 204 = ho gaya par body nahi), 4xx matlab client ki galti (400 galat input, 401 login nahi kiya, 403 permission nahi, 404 cheez hi nahi, 409 conflict jaise duplicate email), 5xx matlab server ka apna crash. Bahut log galti karte hain — sab kuch 200 bhej dete hain aur body me {error:...} daal dete hain. Yeh galat hai, kyunki monitoring aur client libraries status code pe depend karti hain.
Idempotency important concept hai: GET, PUT, DELETE ko N baar maaro to result same rehta hai, par POST har baar naya banata hai. Isliye network timeout ke baad POST retry karna risky hai (double payment ho sakta hai), par PUT/DELETE safe hai. Versioning isliye chahiye kyunki ek baar clients depend kar gaye to API ka shape badalna unhe tod dega — /v1/..., /v2/... rakho taaki purane apps chalte rahein. Aur pagination: 50 lakh rows ek saath mat bhejo — limit aur offset se window do (offset = (page-1)*limit), ya live feed ke liye cursor pagination use karo jo data badalne par bhi stable aur fast rehta hai. Bas inhe samjho aur tumhari API clean, predictable aur scale-able ban jaayegi.
