Path Parameters

Path parameters identify a specific server-side resource as part of an HTTP request URL. Frontend code commonly inserts an identifier into the URL path when fetching one resource or a nested resource.

A path parameter is a variable segment embedded in a URL path, such as `/users/42`, where `42` identifies a particular user. The server or router defines the parameterized route, for example `/users/:id`, and extracts the value when handling the request.

From frontend JavaScript, the parameter is usually constructed before calling `fetch()`. For example, `fetch(`/api/users/${userId}`)` requests the resource associated with `userId`. The parameter becomes part of the URL itself, rather than being placed in the request body.

Path parameters are especially useful when the requested resource is naturally identified by a required value. A route such as `/products/123` communicates that the client is requesting product `123`, while `/products` might represent the collection of products.

A path parameter is different from a query parameter. Query parameters follow a `?`, such as `/products?category=books`, and commonly express filtering, sorting, pagination, or other optional request settings. Path parameters generally identify which resource or sub-resource is being addressed.

Because path parameters become part of the URL, values should be encoded appropriately when they can contain characters with special meaning in URLs. Authentication and authorization should also be handled separately; putting an identifier in a path does not grant permission to access that resource.

Key points

• Path parameters are variable values embedded in the URL path.
• They commonly identify a specific resource, such as `/users/42`.
• Frontend code can construct parameterized URLs before calling `fetch()`.
• They differ from query parameters, which appear after `?` and commonly control filtering or other optional behavior.
• A path parameter is an identifier, not an authorization mechanism.

Interview questions

When would you choose a path parameter instead of a query parameter?

I would use a path parameter when the value is part of identifying the resource being addressed, such as `/orders/123`. I would use query parameters when the request is still targeting a collection or resource but needs optional constraints such as filtering or pagination, such as `/orders?status=pending`. The distinction is primarily about the resource's URL structure and API semantics, rather than a frontend-specific rule.

What is a path parameter, and why would an API use one?

A path parameter is a variable value embedded in the URL path. It is commonly used to identify a particular resource, such as `/users/42` for user 42. The server's routing logic extracts the value and uses it to determine which resource should be handled. From the frontend, the URL can be constructed and passed to `fetch()`.

How would you fetch a user with ID 42 from the frontend?

I would construct the endpoint using the user's ID and pass it to `fetch()`, for example `fetch(`/api/users/${userId}`)`. With `userId` equal to `42`, the request URL is `/api/users/42`. I would then check the response and parse its JSON when appropriate. If the parameter comes from arbitrary input, I would also consider URL encoding.

What security concerns should you consider when using IDs in path parameters?

An ID in a URL should be treated as visible request data, not as a secret. The server must authenticate the caller when required and authorize access to the specific resource. An endpoint such as `/users/42` should not assume that knowing `42` is sufficient permission to retrieve that user. The application should also validate the parameter and safely construct or encode URLs.