It had the benefit of simplicity — endpoints are intuitively named and can be browsed easily. Initially we even implemented URL properties on all objects so the API was browsable just by clicking (this was eventually removed in favor of smaller response payloads). Documentation described what was returned by each endpoint so our mobile team could easily integrate.
Je creuse pas mal GraphQL (cache) en ce moment car nous sommes soumis aux mêmes problèmes rencontrés dans cet article sur data.gouv.fr. Je n’ai réalisé que récemment l’intérêt que cela pouvait avoir pour créer des API hypermedia. Les informations retournées étant générées à la demande cela permet de ne charger les liens dans le payload de la réponse que pour les personnes/robots intéressés. Il en va de même pour toute la sémantisation optionnelle des données retournées. Performance pour les uns, robustesse pour les autres.
De la même manière, il serait possible d’avoir plusieurs endpoints GraphQL correspondant aux différentes ressources et limitant de facto les problèmes de performances liés à la profondeur des informations demandées (si on limite à 1, voire 2 niveaux). L’opposition que l’on fait entre REST et GraphQL (cache) est peut-être une erreur car une approche combinée permettrait d’exploiter le meilleur des deux mondes…