Quelques réponses sur un billet qui a beaucoup circulé : The lie of the API.
Ça flatte beaucoup la mouvance HATEOAS mais je n’accroche pas. Même avec des clients très smart, impossible de faire un même site pour les visites « navigateur » et les accès « API ».
Le logiciel client de l’API ne sera jamais assez intelligent pour comprendre autant le contexte que l’humain derrière son navigateur, et jamais assez souple pour gérer des changements non prévus.
Donc partons de notre bibliothèque qui expose des collections avec des contenus, chacun reliés à des auteurs.
Et si demain je change mes représentations pour ne plus mettre les bio des auteurs dans la fiche du livre directement ? Certes techniquement il est possible de faire un robot qui sache récupérer cette bio sur la fiche de l’auteur, mais quelle est la probabilité que les robots actuels gèrent le changement ?
Et si demain le site web est changé pour que le point d’entrée premier soit l’auteur ? Le logiciel saura-t-il rechercher un livre dont il ne connait pas l’adresse ?
Et si demain je change le système de classification des livres pour passer de BISAC à la CLIL française ? Quelle probabilité que le robot et l’applicatif derrière gère ça de façon transparente ?
La partie destinée au robot (qu’on nomme généralement « API ») n’a simplement pas les mêmes besoins que la partie destinée aux humains (qu’on nomme souvent « web »). On peut faire concilier les deux au début, mais ça va casser au fur et à mesure des évolutions de la partie destinée aux humains.
Tout ça pour quoi ? La satisfaction intellectuelle du développeur qui se dit qu’il correspond au schéma idéal du web. La valeur ajoutée ne me semble pas justifier le risque.
C’est d’autant plus vrai qu’en réalité les clients qui codent des robots hypermedia corrects il n’y en a pas tant que ça. Rapidement des tiers vont coder des robots en faisant de l’ingénierie inverse sur les adresses, les identifiants, la structure, les données. Ça sera peut être de leur faute, mais ça va casser si vous faites des changements en vous reposant uniquement sur le côté hypermedia.
D’où la question : Souhaitez-vous que ça fonctionne ou avoir raison ?
2 réponses à “The lie of the API”
troll bait. :)
Mais il n’y a pas de réponses à ton billet car il démarre sur une fausse caractérisation.
« Le logiciel client de l’API ne sera jamais assez intelligent pour comprendre autant le contexte que l’humain derrière son navigateur, et jamais assez souple pour gérer des changements non prévus. »
Je reformule pour montrer.
« Le tracteur ne sera jamais assez intelligent pour comprendre autant le contexte que le conducteur derrière son véhicule, et jamais assez souple souple pour gérer la glace imprévue sur la route. »
Ce qui est un beau cheval blanc d’Henri IV. ;) Ce n’est pas ce qui est proposé dans une API hypermedia quelconque que ce soit d’ailleurs sous forme JSON ou sous forme HTML. :) Mais j’ai déjà écrit un billet sur le sujet avec un élément important dans le billet sur la notion de besoin de marché (aka interopérabilité) entre les APIs.
:)
Tu m’embêtes parce que tu ne réponds pas aux cas concrets donnés plus bas. Là je ne peux rien faire avec ton commentaire, et je ne comprends rien à ta reformulation. Le pire c’est que tu dis que tu as un billet qui peut aider à réfléchir mais tu n’en donnes pas l’URL et ton blog refuse les moteurs de recherche. Bref, tu veux dire quoi ?