Nested routes versus query params for related resources

WHAT THIS TESTS Whether the candidate can reason about REST URL design tradeoffs rather than memorizing one rule, balancing clarity, flexibility, and consistency.

A GOOD ANSWER COVERS Nested routes such as GET /authors/:authorId/books express the relationship structurally: the books are scoped to a parent author, the hierarchy is self-documenting, and it maps cleanly to authorization where you check access to the author first. The downside is rigidity: deep nesting (/authors/:id/books/:id/reviews) becomes unwieldy, and the same book may need to be addressed independently. Query parameters on a flat collection, GET /books?authorId=123, treat books as a top-level resource and use parameters for filtering. This is far more flexible for combining filters (genre, year, author), pagination, and sorting, and it keeps a single canonical path for a book. A widely used compromise is a shallow nested route for the primary relationship plus a flat, filterable collection, while keeping individual resources at /books/:id rather than nesting their identity.

COMMON WRONG ANSWERS Insisting nesting is always correct or always wrong. Nesting more than one or two levels deep. Duplicating create or update logic across both styles inconsistently. Embedding the parent id in the path for a resource that has its own stable identity.

LIKELY FOLLOW-UPS How deep should nesting go? Where do you put filtering, sorting, and pagination? How does each style interact with caching and authorization? What is the canonical URL for a single book?

ONE CONCRETE EXAMPLE Expose GET /authors/:authorId/books to list one author's books in a clearly scoped, authorization-friendly way, but also support GET /books?authorId=123&genre=scifi&page=2 for rich filtering across the whole catalog, and keep a single book at GET /books/:bookId rather than /authors/:authorId/books/:bookId, so the book has one stable canonical address.