Maybe this one will be considered a marginal answer, and I do not know all the details of this case, but I came to a conclusion that using a graph instead of "linear" API can save your day.

The exact technology for a graph does not matter much (can be JSON-LD, RDF, GraphQL - you name it), but what is important is the ability to transfer subgraphs from one system to another.

In this way, one can easily include all relationships of the child object. There still may be some missing foreign key concerns in the legacy (presumably relational database-powered) system, but graph API can be conceptually easier because it allows to exchange logically aggregated entities right at the transactional borders of those aggregates.

Of course, some kind of framework is needed to simplify graph processing, but the resulting system and API may be more flexible, especially if the use cases of the API are many and diverse. Graph API is also easily extendable, robust, and require much less requests to exchange the data.

The downside may be familiarity of the development team with the technology and query languages.

Also, no RESTful dogma prevents you from having simple CRUD APIs and graph API for more complex updates / queries.

Maybe this one will be considered a marginal answer, and I do not know all the details of this case, but I came to a conclusion that using a graph instead of "linear" API can save your day.

The exact technology for a graph does not matter much (can be JSON-LD, RDF, GraphQL - you name it), but what is important is the ability to transfer subgraphs from one system to another.

In this way, one can easily include all relationships of the child object. There still may be some missing foreign key concerns in the legacy (presumably relational database-powered) system, but graph API can be conceptually easier because it allows to exchange logically aggregated entities right at the transactional borders of those aggregates.

Of course, some kind of framework is needed to simplify graph processing, but the resulting system and API may be more flexible, especially if the use cases of the API are many and diverse. Graph API is also easily extendable, robust, and require much less requests to exchange the data.

The downside may be familiarity of the development team with the technology and query languages.

Also, no RESTful dogma prevents you from having simple CRUD APIs and graph API for more complex updates / queries.

One more note: tree is also a graph. Can be used to increase performance of operations and does not require special format (JSON or XML would be enough).

Maybe this one will be considered a marginal answer, and I do not know all the details of this case, but I came to a conclusion that using a graph instead of "linear" API can save your day.

The exact technology for a graph does not matter much (can be JSON-LD, RDF, GraphQL - you name it), but what is important is the ability to transfer subgraphs from one system to another.

In this way, one can easily include all relationships of the child object. There still may be some missing foreign key concerns in the legacy (presumably relational database-powered) system, but graph API can be conceptually easier because it allows to exchange logically aggregated entities right at the transactional borders of those aggregates.

Of course, some kind of framework is needed to simplify graph processing, but the resulting system and API may be more flexible, especially if the use cases of the API are many and diverse. Graph API is also easily extendable, robust, and require much less requests to exchange the data.

The downside may be familiarity of the development team with the technology and query languages.

Maybe this one will be considered a marginal answer, and I do not know all the details of this case, but I came to a conclusion that using a graph instead of "linear" API can save your day.

The exact technology for a graph does not matter much (can be JSON-LD, RDF, GraphQL - you name it), but what is important is the ability to transfer subgraphs from one system to another.

In this way, one can easily include all relationships of the child object. There still may be some missing foreign key concerns in the legacy (presumably relational database-powered) system, but graph API can be conceptually easier because it allows to exchange logically aggregated entities right at the transactional borders of those aggregates.

Of course, some kind of framework is needed to simplify graph processing, but the resulting system and API may be more flexible, especially if the use cases of the API are many and diverse. Graph API is also easily extendable, robust, and require much less requests to exchange the data.

The downside may be familiarity of the development team with the technology and query languages.

Also, no RESTful dogma prevents you from having simple CRUD APIs and graph API for more complex updates / queries.