Query Strings vs. Path Parameters: Building URLs Safely

Path parameters identify which resource you want — /posts/42 means "post number 42" — while query parameters filter, sort, or configure how you want it — /posts?sort=newest. As a rule of thumb: if removing the value would mean a completely different resource, it belongs in the path; if it just changes how the same resource is presented, it belongs in the query string.

When to use path parameters

Path parameters suit resource identification and hierarchy: /posts/42, or /folders/12/files/7 for a file nested inside a folder. They read cleanly, cache predictably (since the URL itself is the identity of the resource), and are the natural fit whenever a value is required, not optional — a post detail page doesn't make sense without knowing which post.

When to use query parameters

Query parameters suit anything optional, filterable, or combinable: /posts?category=tech&sort=newest&page=2. Real-world APIs — GitHub's included — consistently use path parameters to identify which resource, and query parameters to filter or paginate results on top of it, which is a reliable pattern to copy when designing your own URLs.

Encoding both correctly

Both path segments and query values need percent-encoding when they contain unsafe characters, but the specific set of characters that need encoding differs slightly between the two contexts — a / is meaningful (a segment separator) in a path but harmless inside a properly-encoded query value. The safest approach is never hand-building either by string concatenation: use your framework's URL-building utilities, or encode dynamic values individually before inserting them, rather than assuming a user-provided string is already safe to drop into either position.