A common scenario where a partial failure may occur is throttling. If you have a client that is permitted to perform 10 query per second and they submit a GraphQL request with 11 queries, the server is within its rights to return the results of the first 10 queries and an error for the 11th. This would allow the client to only retry the 11th query rather than all 11 (which, if throttling were enforced at the request level, would always result in a 429 response).
Interesting, I see how that would not be as easily replicated with traditional REST. You would either need a bunch of requests or your client would need to be intimately familiar with the API. This leads me to think GQL has some benefits when used for semi-public/cross-team consumption (as opposed to a tight relationship between server and client or more monolithic apps), as there is more “opinion” in place by design to allow clients less familiar with the intricacies of the API to still use it efficiently. This is also furthered by another commentor pointing out the cross-protocol capability of GQL, as maybe different teams or companies integrating your API may have different needs in that way. Thanks for the info!
