REST API Design — Conventions Interviewers Expect You to Know

Whether you're building an Express API or consuming one, these conventions are the shared language of web teams.

Resources are nouns; methods are verbs

GET    /api/students          # list (with filters)
GET    /api/students/42       # one
POST   /api/students          # create → 201 + the created object
PUT    /api/students/42       # replace
PATCH  /api/students/42       # partial update
DELETE /api/students/42       # remove → 204

# nested relations — one level max
GET /api/students/42/marks

# ❌ never: /getStudents, /student_delete.php?id=42

Query params = filtering; path = identity

GET /api/students?dept=cse&sort=-cgpa&page=2&limit=20

Error responses — pick a shape, keep it

// 400
{ "error": { "code": "VALIDATION", "message": "cgpa must be 0–10", "field": "cgpa" } }

Consistent error shapes are what make frontends pleasant to write against — inconsistent APIs are why frontend devs drink chai angrily.

Rapid-fire conventions

• Version from day one: /api/v1/…
• Plural nouns, lowercase, hyphens
• PUT/DELETE are idempotent (same call twice = same result) — a favorite interview probe
• Status codes from the status code guide — 200/201/204/400/401/403/404/500 cover almost everything