# Hypermedia à la demande

2015-10-13

> 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.

> From REST to GraphQL (cache)

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…

Articles choisis : Commodité et effondrement, Des données aux communs, Accompagner un enfant, Senior developer, L’illusion sociale, Instantané Scopyleft, Enseigner le Web, Simplicité par défaut, Minimalisme et esthétique, Travail en transition, La pairmutation du travail, Principes Web, Travail en transition, Un web omni-présent, Manifeste de développeur, Confort et convivialité, Testament numérique, et bien d’autres…