req.params vs req.query vs req.body in Express

WHAT THIS TESTS This verifies you know exactly where each kind of client input arrives and can map them to typical REST use cases.

A GOOD ANSWER COVERS req.params holds values captured from named placeholders in the route path, like :id in /users/:id, and is used to identify a specific resource. req.query holds the parsed query string, the key-value pairs after the ? in the URL, and is ideal for optional inputs like filtering, sorting, and pagination. req.body holds the parsed request payload sent by the client, typically JSON or form data, and requires a body parser such as express.json() or express.urlencoded() to be populated; otherwise it is undefined. The rule of thumb: params identify, query refines, body carries the data you submit.

COMMON WRONG ANSWERS Confusing req.query with req.params, for instance expecting /users/:id to populate req.query. Expecting req.body to work without registering a parser. Putting large or sensitive payloads in the query string. Thinking GET requests can read a meaningful req.body.

LIKELY FOLLOW-UPS Which one would you use for pagination? Why is req.body undefined without a parser? Are query values always strings (yes, so you must coerce numbers)? How do you validate each source?

ONE CONCRETE EXAMPLE app.get('/users/:id', (req, res) => { const id = req.params.id; }); reads the resource id from the path. app.get('/users', (req, res) => { const page = req.query.page; }); reads ?page=2 for pagination. app.post('/users', (req, res) => { const { name } = req.body; }); reads the submitted JSON payload. A single endpoint can use all three: PATCH /users/:id?notify=true with a JSON body uses params for id, query for the notify flag, and body for the updated fields.