Hierarchical resource paths in Rest API - Time & Space Complexity
When working with hierarchical resource paths in REST APIs, it's important to understand how the number of operations grows as the API handles nested resources.
We want to know how the time to process requests changes when the depth or number of nested resources increases.
Analyze the time complexity of the following REST API path handling.
GET /users/{userId}/orders/{orderId}/items
// The server fetches user data,
// then fetches the order for that user,
// then fetches all items in that order.
This code represents a hierarchical path where each resource depends on the previous one.
Look for repeated actions or loops in handling nested resources.
- Primary operation: Fetching items in the order (likely a list traversal)
- How many times: Once per item in the order, which depends on the number of items
As the number of items in an order grows, the time to fetch all items grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 items | About 10 fetch operations |
| 100 items | About 100 fetch operations |
| 1000 items | About 1000 fetch operations |
Pattern observation: The operations increase directly with the number of items.
Time Complexity: O(n)
This means the time to handle the request grows linearly with the number of items in the nested resource.
[X] Wrong: "Fetching nested resources is always constant time because it's just one API call."
[OK] Correct: Even though the path looks like one call, the server often fetches each nested resource separately, so time grows with the number of nested items.
Understanding how nested resource paths affect time helps you explain API performance clearly and shows you can think about real-world data sizes.
What if the API used pagination to limit items returned per request? How would that change the time complexity?