Query Parameters vs Path Parameters vs Request Body
The three places input goes on a request: the path for which thing, after the question mark for how you want it, the body for the data.
See it
What it is
Three slots, three jobs. Path parameters name the thing: in '/users/42/invoices/7', the 42 and the 7 are path params, and changing them points you at a different resource. Query parameters are the key=value pairs after the '?': '?status=open&sort=-created&limit=50'. They filter, sort, paginate, and shape the same resource. The request body carries the data itself, usually JSON, on POST, PUT, and PATCH.
Rule of thumb: if removing it makes the URL point somewhere else, it is a path param. If it refines a list you already asked for, query param. If you are writing data, or it is large, nested, or sensitive, body. Optional inputs belong in the query string, not in the path, so you are not inventing '/users//invoices' shapes.
Gotchas: query strings land in server logs, browser history, and Referer headers, so never put an API key or token there. Query values are always strings, so 'false' and '0' arrive truthy unless you parse them. And a body on a GET request is a coin flip: fetch refuses it outright and many proxies drop it, so filters go in the query string even when they get long (or you POST to a '/search' endpoint).
Ask AI for it
Design the REST endpoints for this resource and put every input in the right slot: path parameters for resource identity ('/projects/:projectId/tasks/:taskId'), query parameters for filtering, sorting, and pagination ('?status=open&sort=-createdAt&limit=50&cursor=...'), and a JSON request body for the fields being created or updated. Keep GET and DELETE bodyless, validate query values as strings and coerce them explicitly, and never accept a token or secret as a query parameter.