Read params, query, and body

Start from the behavior you can observe. A note id comes from req.params, a search filter from req.query, and editable content from a parsed form or JSON body.

Parameters, query strings, and bodies have different semantics even though every value still needs validation. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to pull every value from whichever object happens to contain a matching property name. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to define the location and schema of every input in the route contract before reading it. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Design routes that match intentionally, parse input from the correct location, and return one complete response. Record enough evidence that another developer can repeat the result without relying on your memory.

Send the same key in all three locations and prove the handler uses only the documented source. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.