I tend to be highly critical of the costs of interfaces that bring nested data structures into the equation, especially on the input layer. The moment you bring

I tend to be highly critical of the costs of interfaces that bring nested data structures into the equation, especially on the input layer. The moment you bring nesting into the equation, things become exponentially more complex. There's a reason relational databases are relational databases and not graph databases. Flat data structures bring a lot of simplicity in expectations. Two dimensions are easy to grasp. You can see at a glance if things are going right or wrong. You'll notice immediately. The same goes for API interfaces. A one dimensional list of input parameters is easy to understand. The length of your input vector is equal to your degrees of freedom. Easy to understand. However, with a graph query, you can query literally anything in any dimension you want. _Sometimes_ that can be powerful, but more often, you want API contracts to be strict and simple. Simple REST endpoints will bring less surprises, are easier to document, easier to explain and easier to implement. Sure, there is the cost of doing multiple queries. But for how many applications is the added complexity worth the cost? HTTP is getting faster everyday, especially with HTTP2 and HTTP3. Multiple queries aren't as much of a deal breaker as they were 10 years ago. In complex applications, simplicity and predictability are more important than minor performance improvements.