Resource identifiers in URLs in Rest API - Time & Space Complexity
When using resource identifiers in URLs, it's important to see how the system handles requests as the number of resources grows.
We want to know how the time to find or access a resource changes when there are more resources.
Analyze the time complexity of the following code snippet.
GET /users/{userId}
// Server receives a request with a userId in the URL
// It looks up the user in a database or data store by that ID
// Then returns the user data as a response
This code handles a request to get a user by their unique ID from a collection of users.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Searching for the user by ID in the data store.
- How many times: Depends on the data structure; could be one direct lookup or a search through all users.
As the number of users grows, the time to find one user depends on how the data is stored.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 or 1 (depending on lookup method) |
| 100 | 100 or 1 |
| 1000 | 1000 or 1 |
Pattern observation: If the system searches through all users, operations grow with n; if it uses direct lookup, operations stay about the same.
Time Complexity: O(1)
This means finding a user by their ID takes about the same time no matter how many users there are, assuming a direct lookup method.
[X] Wrong: "Finding a user by ID always takes longer as the number of users grows."
[OK] Correct: Many systems use direct lookup methods like hash tables or indexed databases, so the time stays constant regardless of size.
Understanding how resource identifiers affect lookup time helps you explain efficient API design and data access in real projects.
"What if the user data was stored in a simple list without indexing? How would the time complexity change?"
Practice
Solution
Step 1: Understand resource identifiers
Resource identifiers are unique parts of a URL that point to a specific item or resource.Step 2: Identify their role in REST APIs
They help the server know exactly which resource the client wants to access or modify.Final Answer:
To uniquely identify a specific resource -> Option AQuick Check:
Resource identifiers = unique resource ID [OK]
- Confusing resource identifiers with HTTP methods
- Thinking resource identifiers define server location
- Mixing resource identifiers with response formats
Solution
Step 1: Identify the standard REST URL format
Resource identifiers usually come directly after the resource name separated by a slash.Step 2: Check each option
/users/42 uses "/users/42" which correctly places the ID after the resource name. /users?id=42 uses a query parameter, which is less common for resource identification. /users/42/details adds extra path which may refer to a sub-resource. /users#42 uses a fragment which is not for resource IDs.Final Answer:
/users/42 -> Option DQuick Check:
Resource ID follows resource name with slash [OK]
- Using query parameters instead of path segments
- Adding extra path parts that change meaning
- Using URL fragments (#) for resource IDs
/products/123/reviews/456, which resource does the identifier 456 represent?Solution
Step 1: Break down the URL path
The URL has two resource names: "products" and "reviews" with IDs 123 and 456 respectively.Step 2: Understand the hierarchy
"reviews/456" comes after "products/123", so 456 is the review ID related to product 123.Final Answer:
Review with ID 456 for product 123 -> Option BQuick Check:
Last ID is for last resource in URL [OK]
- Mixing IDs and thinking 456 is a product ID
- Ignoring resource hierarchy in URL
- Assuming IDs apply to all resources
/orders/ 789Solution
Step 1: Analyze the URL structure
The URL shows/orders/and then789separately, which suggests the ID is not part of the path.Step 2: Understand correct resource ID placement
The ID should be directly after the resource name in the same path segment, like/orders/789.Final Answer:
The ID should be part of the path, not separate -> Option CQuick Check:
Resource ID must be in the path segment [OK]
- Placing ID outside the URL path
- Removing the slash between resource and ID
- Thinking resource ID comes before resource name
Solution
Step 1: Understand resource hierarchy
The comment belongs to a post, so the post resource should come first in the URL.Step 2: Check each URL option
/posts/101/comments/555 correctly places the post ID first, then the comments resource with its ID. Other options mix the order or IDs incorrectly.Final Answer:
/posts/101/comments/555 -> Option AQuick Check:
Parent resource ID before child resource ID [OK]
- Reversing parent and child resource order
- Mixing IDs between resources
- Placing IDs in wrong path segments
Ready to prove it?
Pass the test and this pattern moves unknown
