REST describes relationships just fine. Now return a list of 100 documents that each have a list of related comments. Your client just needs to request
GET /documents
GET /documents/1/comments
GET /documents/2/comments
GET /documents/3/comments
GET /documents/4/comments
GET /documents/5/comments
..
GET /documents/99/comments
GET /documents/100/comments
Think of how this can be done on a web page. The documents page has a link to follow, "include comments", which links to "?include=comments". The exact query doesn't matter, what's important is that a client can discover new information without needing any out-of-band information.
The next natural step will be - "Thanks for the comments, now the user needs to sort them by votes/date, ok?" and the URL starts looking like a query anyway, so you're on the way of re-implementing GraphQL. Then do you send avatars/timestamps/changeflags for all comments, or only on main body in this endpoint? Now you have the over/under-fetching problems.
The step after that will be "Oh there are 300 of them - I just want the top 3 comments first, and a pager for the rest ok?" and you simply can't do that with the structure REST mandates.
There is no structure that REST mandates, if there were it would be a specification and not an architectural style. There is nothing that says that you can't query for that:
GET /comments?sort=votes&limit=3
The exact string doesn't matter, what matters is the client can discover this. How HTML does this is by generating query parameters based on form inputs.
