Description
Is your feature request related to a problem? Please describe.
Currently, ZenStack's automatic REST API generates "flat" endpoints for all models (e.g., /thread/1 and /comment/2). While functional, this doesn't reflect the logical ownership and hierarchy of data. For resources that are strictly dependent on a parent—such as a Comment that must always belong to a Thread—a flat structure lacks semantic clarity and forces the client to manually manage foreign keys in every request.
Without nested routing, the API doesn't express the constraint that a child resource's lifecycle is bound to its parent.
Describe the solution you'd like
I would like the ability to configure hierarchical or "nested" endpoints within the automatic REST API. This would allow for URLs like:
GET /threads/:threadId/comments/:commentId
Key Requirements:
- Logical Scoping: Accessing a child via a nested route should automatically apply a filter to ensure the child actually belongs to the specified parent.
- Simplified Creation: A
POST to /threads/1/comments should automatically associate the new comment with threadId: 1 without requiring the ID in the request body.
- ZModel Configuration: Ideally, this could be defined in the
.zmodel file using an attribute (e.g., @@http.path) or via the plugin configuration to specify parent-child relationships for routing.
Example Structure:
If a Thread has many Comments:
GET /threads/1/comments — Fetches all comments for thread 1.POST /threads/1/comments — Creates a comment specifically for thread 1.GET /threads/1/comments/2 — Fetches comment 2, but only if it belongs to thread 1 (returning 404 otherwise).
Describe alternatives you've considered
- Flat Endpoints with Filters: Using
GET /comment?threadId=1. While this works, it is less RESTful and doesn't enforce the hierarchy at the routing level.
- Custom Hooks/Routes: Writing manual Next.js or Express routes to wrap the ZenStack logic. This defeats the purpose of an "Automatic" REST API and increases boilerplate.
Additional context
Hierarchical routing is a staple of mature REST frameworks. For instance:
- Ruby on Rails allows
resources :threads do resources :comments end.
- NestJS and Express developers frequently implement this to improve API discoverability and security through implicit scoping.
This feature would make ZenStack-generated APIs feel significantly more professional and "opinionated" in a way that aligns with standard REST best practices.
References:
Description
Is your feature request related to a problem? Please describe.
Currently, ZenStack's automatic REST API generates "flat" endpoints for all models (e.g.,
/thread/1and/comment/2). While functional, this doesn't reflect the logical ownership and hierarchy of data. For resources that are strictly dependent on a parent—such as aCommentthat must always belong to aThread—a flat structure lacks semantic clarity and forces the client to manually manage foreign keys in every request.Without nested routing, the API doesn't express the constraint that a child resource's lifecycle is bound to its parent.
Describe the solution you'd like
I would like the ability to configure hierarchical or "nested" endpoints within the automatic REST API. This would allow for URLs like:
GET /threads/:threadId/comments/:commentIdKey Requirements:
POSTto/threads/1/commentsshould automatically associate the new comment withthreadId: 1without requiring the ID in the request body..zmodelfile using an attribute (e.g.,@@http.path) or via the plugin configuration to specify parent-child relationships for routing.Example Structure:
If a
Threadhas manyComments:GET /threads/1/comments— Fetches all comments for thread 1.POST /threads/1/comments— Creates a comment specifically for thread 1.GET /threads/1/comments/2— Fetches comment 2, but only if it belongs to thread 1 (returning 404 otherwise).Describe alternatives you've considered
GET /comment?threadId=1. While this works, it is less RESTful and doesn't enforce the hierarchy at the routing level.Additional context
Hierarchical routing is a staple of mature REST frameworks. For instance:
resources :threads do resources :comments end.This feature would make ZenStack-generated APIs feel significantly more professional and "opinionated" in a way that aligns with standard REST best practices.
References: