I am trying to understand whether resources in a RESTFUL API should directly represent the underlying database or not. In particular, a problem that I have is that I usually use highly normalized databases. The result is that if my API always hyperlinks to the children of a parent resource then the network will be unmanageably chatty.
According to the accepted answer here: https://stackoverflow.com/questions/12758219/pure-hateoas-vs-making-too-many-service-calls there is nothing in REST which prohibits child resources from being nested in the representation of their parent resource. However, Roy has also had this to say:
Query results are represented by a list of links with summary information, not by arrays of object representations (query is not a substitute for identification of resources).
(https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven comment 5)I can only interpret this to mean that child object should not be nested in the representation of their parent objects (if they are, then we have a 'list of object representations').
A priori it seems to me that having a total coupling between my database schema and my API design is bad. It forces me to consider network implications when designing my schema. But I want to design my schema based only on normalisation considerations. On the other hand, I can see how too much nesting can reduce the ability to scale the application while maintaining a navigable API.
Is there anything in REST which talks directly to the relationship between which objects are resources that must get URIs, and the database representation? Or do I am I misreading things? Thanks.