URL query parameters

Canonical guidance

• read query params at the HTTP boundary
• convert them into typed inputs
• reject or default invalid values explicitly

Use when

• filtering endpoints
• pagination or sorting inputs
• search and list APIs

Avoid

• handing raw url.Values deep into business logic
• silent parse failures
• assuming repeated keys cannot occur

Preferred pattern

• parse once from r.URL.Query(), validate, then pass a typed filter struct onward

Anti-pattern

• sprinkling r.URL.Query().Get(...) throughout the handler body and downstream helpers

Explanation: This is tempting because query access is cheap, but repeated stringly typed reads spread validation and defaulting logic everywhere.

Why

• typed boundary parsing keeps API behavior predictable and testable