|
123456789 |
- title: Hypermedia à la demande
-
- > 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.
- >
- > <cite>*[From REST to GraphQL](https://blog.jacobwgillespie.com/from-rest-to-graphql-b4e95e94c26b)* ([cache](/david/cache/69b00e4dda3dc06e585c2b7bc6bf1fc2/))</cite>
-
- Je creuse pas mal [GraphQL](https://code.facebook.com/posts/1691455094417024) ([cache](/david/cache/5d248c04318f0d2356b3ea769c6e088e/)) en ce moment car nous sommes soumis aux mêmes problèmes rencontrés dans cet article sur [data.gouv.fr](https://www.data.gouv.fr/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](https://facebook.github.io/relay/docs/thinking-in-graphql.html) ([cache](/david/cache/db7ba122f32c64df26c075bdbbee18fb/)) est peut-être une erreur car une approche combinée permettrait d’exploiter le meilleur des deux mondes…
|
