Consider a REST API with the following hierarchical resource paths:
/users/{userId}/posts/{postId}If a client sends a GET request to /users/42/posts/7, what is the expected resource path matched and the extracted parameters?
Think about how hierarchical paths capture parameters at each level.
The full path /users/42/posts/7 matches the nested resource /users/{userId}/posts/{postId}. Both userId and postId are extracted from the URL.
Why is it beneficial to design REST API resource paths hierarchically, such as /users/{userId}/posts/{postId}, instead of flat paths like /posts/{postId} only?
Think about how URLs reflect real-world relationships.
Hierarchical paths show how resources relate, like posts belonging to a user. This makes APIs easier to understand and use.
Given the following API route definitions:
/users/{userId}/posts/{postId}
/users/{userId}/posts
/users/allA GET request to /users/all/posts returns a 404 error. Why?
Consider how path parameters and static segments are matched.
The path /users/all/posts tries to match /users/{userId}/posts with userId='all'. Since 'all' is not a user with posts, it returns 404. The static path /users/all does not have a nested /posts route.
Which of the following is the correct syntax for defining a hierarchical resource path with two parameters in a REST API?
Look for the standard placeholder format for path parameters.
The standard syntax uses curly braces {} to denote parameters in REST API paths, e.g., {userId}.
An API defines these hierarchical resource paths:
/companies/{companyId}/departments/{departmentId}/employees/{employeeId}
/companies/{companyId}/departments/{departmentId}
/companies/{companyId}If the API has 3 companies, each with 4 departments, and each department has 10 employees, how many unique resource paths exist for /companies/{companyId}/departments/{departmentId}/employees/{employeeId}?
Multiply the counts at each level of the hierarchy.
There are 3 companies × 4 departments each × 10 employees each = 120 unique employee resource paths.