Use top-level single-resource endpoints; parent-scoped list endpoints for scoping (no nested single-resource GET)

[Many0nne]

Description

Keep single-resource endpoints as top-level (e.g., GET /users/{id}, GET /orders/{id}). Do not implement parent-scoped single GET like /parents/{parentId}/children/{childId}. For parent-scoped access, use parent-scoped list endpoints or query-scoped lists that work with pagination/filter/sort.

Acceptance criteria

• Single-resource endpoints remain top-level: GET /users/{id}, GET /orders/{id}.
• Parent-scoped lists available as either:
  • GET /parents/{parentId}/children?page&filter&sort (optional), or
  • GET /children?parentId={parentId}&page&filter&sort
• Parent-scoped list endpoints support pagination/filtering/sorting per the combined list feature.
• Parent-scoped list returns 404 if parent does not exist.
• No nested single-resource route (/parents/{parentId}/children/{childId}) is added.
• Documentation updated to show list scoping conventions and single-resource routes.

API examples

• GET /users/456 -> 200 { user } or 404
• GET /users?organisationId=123&page=1&pageSize=20&sort=createdAt:desc
• (Optional) GET /organisations/123/users?page=1&pageSize=20

Implementation notes

• Single-resource retrieval: query child by id only.
• Parent-scoped lists: filter by parentId in DB (ensure parent exists when using parent-scoped list route).
• Keep response shapes consistent and update routing/docs; add deprecation notes only if removing old routes.