URL Parameters

Understanding URL Parameters

When you build a backend, you often need to receive information from the client as part of the URL itself. URL parameters are one of the main ways to do this.

In this chapter you will learn what URL parameters are, how they differ from other kinds of request data, and how they are used in typical backend routes.

What URL Parameters Are

A URL is usually written like this:

text

https://example.com/users/42

Here, /users/42 is the path. The part 42 is not a fixed word like users. It is a value that can change, for example:

/users/1
/users/2
/users/12345

That variable part of the path is what we call a URL parameter or path parameter.

In a route definition, you usually describe it as a pattern, for example (in a Python style):

python

GET /users/{user_id}

The {user_id} is a placeholder that will match values like 1, 42, or 999.

URL parameters belong to the path segment of the URL. They are part of the structure of the endpoint and they usually identify which resource you are working with.

Important rule:
URL (path) parameters are part of the path itself and are used to identify specific resources, such as /users/{id} or /posts/{slug}.

URL Parameters vs Query Parameters vs Request Body

Even though this chapter focuses on URL parameters, you will see different ways to send data to a backend. It is important to understand how URL parameters differ from the others.

URL Parameters

Located inside the path, for example:
/products/123, /users/alice/orders/5
Typically used to say which resource you want:

A specific user: /users/42
A specific article: /articles/2024-hello-world

Required by the route. If you omit them, the URL is different.

Query Parameters

Added after a question mark ? at the end of the URL, for example:
/products?category=books&sort=price_asc
Used to filter, sort, or search among resources:

Filter by category
Set page number
Sort order

Optional in many cases.

Request Body

Sent inside the HTTP request body, not in the URL.
Typically used to send larger or more complex data:

JSON for creating or updating a resource
Form data when submitting forms

Not visible in the URL.

You will see query parameters and request bodies in later chapters. Here, only focus on URL parameters.

Aspect	URL Parameters	Query Parameters	Request Body
Location	Path, e.g. `/users/42`	After `?`, e.g. `?page=2`	Inside HTTP body
Typical usage	Identify a resource	Filter, sort, search, options	Create or update data
Required / optional	Usually required	Often optional	Depends on endpoint
Visible in URL	Yes	Yes	No

Common Use Cases for URL Parameters

URL parameters are usually used when you need to identify a specific item or a combination of hierarchical items.

Identifying a Single Resource

A very common pattern in REST APIs is:

/users/{user_id}
/products/{product_id}
/orders/{order_id}

Examples:

text

GET /users/42
GET /products/999
DELETE /orders/123

In each one, the last part of the URL is a parameter:

42 is the user_id
999 is the product_id
123 is the order_id

The server uses this value to look up the corresponding record in the database.

Nested Resources

Sometimes a resource belongs to another resource. For example, comments on a blog post:

text

GET /posts/13/comments
GET /posts/13/comments/2

Parameters here:

13 is post_id
2 is comment_id

The second route might mean: “get comment 2 that belongs to post 13.”

Using Human-Friendly Identifiers (Slugs)

Not all parameters must be numeric. You can also use slugs or strings:

text

GET /articles/what-is-backend-development
GET /categories/web-development/articles

The parameter what-is-backend-development might be an article_slug that the backend looks up.

Multiple Parameters in the Same Path

You can have more than one parameter:

text

GET /users/{user_id}/orders/{order_id}
GET /teams/{team_id}/members/{member_id}

Example URLs:

text

GET /users/10/orders/5
GET /teams/3/members/7

Here, the route structure gives more context:

user_id = 10, order_id = 5
team_id = 3, member_id = 7

How URL Parameters Are Defined in Routing

In the “Routing” chapter you saw that the backend server matches incoming URLs to specific handler functions. URL parameters are part of this routing pattern.

Although different frameworks use slightly different syntax, they all share the same concept: a placeholder inside the path.

Pattern Based Route Definitions

Below is a pseudo style that looks similar to many backend frameworks:

python

# Pattern with a URL parameter
GET /users/{user_id}

The handler might look like:

python

def get_user(user_id):
    # user_id comes from the URL, like /users/42
    ...

When a request arrives:

If the path looks like /users/42, the route /users/{user_id} matches.
The framework extracts 42 and passes it as user_id to the handler.

If the path is /users, with no /{user_id}, this route does not match.

Matching Multiple Routes

You can define more than one route under the same base path:

text

GET /users               # list users
GET /users/{user_id}     # get a specific user

Example behavior:

GET /users might return all users.
GET /users/5 might return user with ID 5.

The presence of a value in the {user_id} position is what makes the second route match.

Data Types of URL Parameters

Even though every URL is a string, many frameworks let you specify what type your URL parameter should have, for example integer, string, or UUID.

String Parameters

Default type is often string:

text

GET /articles/{slug}

Example:

text

GET /articles/hello-world

The string hello-world becomes the slug parameter in the handler.

Integer Parameters

Integers are common for IDs:

text

GET /users/{user_id}

Example:

text

GET /users/123

The parameter user_id has the value 123, but in code it is treated as an integer instead of a string.

If a framework expects an integer and the URL contains text like /users/abc, the framework will usually reject the request, often with a 404 Not Found or 422 Unprocessable Entity.

UUID Parameters

Some APIs use UUIDs instead of numeric IDs:

text

GET /resources/{resource_id}

Example:

text

GET /resources/550e8400-e29b-41d4-a716-446655440000

The parameter resource_id is a UUID. The route pattern tells the framework to parse it as such.

Important statement:
Even though URL parameters are strings in the URL, frameworks can parse and validate them as typed values such as integers or UUIDs.

URL Encoding in Parameters

URL paths can only safely contain a limited set of characters. If you need to use characters like spaces, ?, #, /, and others, the browser encodes them.

This process is called URL encoding or percent encoding.

Examples of Encoded Characters

Character	Encoded form
space	`%20`
`/`	`%2F`
`?`	`%3F`
`#`	`%23`

If you have a parameter that might contain spaces, for example a username:

text

/users/John Doe

The actual request URL might become:

text

/users/John%20Doe

The framework will decode %20 back into a space. In your handler, you will receive John Doe.

When This Matters

If you manually type URLs in tests, you must remember to use the encoded version.
If you log raw URLs, you will see the encoded values in the path.
When designing APIs, it is usually simpler to choose parameter values that avoid many special characters, for example using hyphens in slugs.

Designing Clear Paths with URL Parameters

The way you design URL parameters affects how understandable your API is.

Use Nouns, Not Verbs, in Paths

Paths should represent resources, not actions. Use HTTP methods to represent actions.

Less clear:

text

GET /getUser/42
POST /createUser

Clearer:

text

GET /users/42
POST /users

/users/42 uses a URL parameter 42 to identify the user.

Put the Identifier in the URL Parameter Position

If you need to work with a single resource, put its identifier in the path:

Get single user: GET /users/{user_id}
Update user: PUT /users/{user_id}
Delete user: DELETE /users/{user_id}

You will see this pattern often in REST APIs.

Use Hierarchy for Nested Resources

Sometimes a resource is naturally dependent on another. For example, a comment belongs to a post.

Common patterns:

text

GET /posts/{post_id}/comments
GET /posts/{post_id}/comments/{comment_id}

This shows that the comment is tied to the post.

Error Cases and Edge Cases with URL Parameters

When using URL parameters, some common issues can appear.

Missing Parameters

If a route expects /users/{user_id}, then:

/users is missing the parameter and might match a different route, for example a list users route.
If there is no such route, you will likely get a 404 Not Found.

Example:

Defined routes:

GET /users → list all users
GET /users/{user_id} → get a specific user

Requests:

GET /users → OK, hits the "list users" handler.
GET /users/5 → OK, hits the "get user" handler.
GET /users/ (with trailing slash) might be handled differently depending on the framework.

Invalid Parameter Format

If a parameter is supposed to be an integer but the client sends a string that cannot be converted, such as /users/abc, there are two typical behaviors:

Framework returns 404 Not Found, because /users/abc does not match the integer pattern.
Or the framework returns a validation error, for example 400 Bad Request or 422 Unprocessable Entity.

In both cases, the handler usually does not run because the route did not match correctly.

Resource Not Found

Sometimes the URL format is correct, but the resource does not exist. For example:

text

GET /users/9999

9999 is a valid integer. But if there is no user with ID 9999 in the database, your handler will typically return 404 Not Found.

It is important to distinguish:

Route does not match: URL shape is wrong, or parameter cannot be parsed, so the framework might return 404 before your handler.
Resource does not exist: Route matches, but your code does not find any record, so your handler returns 404.

Summary

URL parameters are variable parts of the URL path that let you identify specific resources. Typical patterns include:

/users/{user_id}
/products/{product_id}
/posts/{post_id}/comments/{comment_id}
/articles/{slug}

They are:

Part of the path, not after ?.
Usually required for that route.
Often used to select a single resource or express a hierarchy.

You saw how they differ from query parameters and request bodies, how frameworks typically extract and validate them, and how to design clear, readable paths that use parameters effectively.

In the next chapters, you will use URL parameters together with query parameters and request bodies to build more complete endpoints.

URL Parameters

Understanding URL Parameters

What URL Parameters Are

URL Parameters vs Query Parameters vs Request Body

URL Parameters

Query Parameters

Request Body

Common Use Cases for URL Parameters

Identifying a Single Resource

Nested Resources

Using Human-Friendly Identifiers (Slugs)

Multiple Parameters in the Same Path

How URL Parameters Are Defined in Routing

Pattern Based Route Definitions

Matching Multiple Routes

Data Types of URL Parameters

String Parameters

Integer Parameters

UUID Parameters

URL Encoding in Parameters

Examples of Encoded Characters

When This Matters

Designing Clear Paths with URL Parameters

Use Nouns, Not Verbs, in Paths

Put the Identifier in the URL Parameter Position

Use Hierarchy for Nested Resources

Error Cases and Edge Cases with URL Parameters

Missing Parameters

Invalid Parameter Format

Resource Not Found

Summary

Comments

Where to Move