Here is the scenario. I want to create a backend for a TODO list application, but I’m not 100% sure the best way to structure my routes. I was thinking I could do something like this:
POST @ /api/register
POST @ /api/login
GET @ /api/users/:userId/projects
GET @ /api/users/:userId/projects/:projectId/tasks
POST @ /api/users/:userId/projects/:projectId/tasks/:taskId
My first question is this… is it a bad idea to have deeply nested routes like this? I’ve read that it is ok to use sub-resources if we know the sub-resource can NOT exist without the parent resource. So in this case, yes, a project can’t exist without a user, and a task can’t exist without a project, but I also read that having flat rest resources is also good in some cases. I could see some cons being that down the road if I decide to allow multiple users to view and add to shared projects, this nested structure is going to need to be refactored, but the pro is route seems fairly easy to understand.
My second question is in regards to permissions. What is the “proper” way to verify a user has access to get / edit / delete these projects / tasks? Since I’m using express and JWT, I assume I could just create a middleware function which checks the user’s JWT and compares the userId it would contain against the req.params.userId to verify if the user has permission to do stuff on the projects or tasks. If the req.params.userId !== jwt.userId, I just return a 403 error back to the user? Again, if I decide to let multiple users permission to view different projects, this approach wouldn’t work since I’d need to check the jwt.userId against some external list (maybe I’d need to implement ACL?)
I’m open to any alternative solutions and suggestions as to what you think the best way to implement this simple REST api would be.