J’ai remarqué un petit détail, mais très utile, dans la documentation de l’interface de nœud de @Dusk pour les wallets et les exchanges : les réponses du nœud incluent une « Rusk-Version », et les clients peuvent aussi indiquer au nœud les versions qu’ils acceptent. Si « Rusk-Version-Strict » est incluse, le nœud rejettera immédiatement la requête lorsque les versions ne correspondent pas.
Beaucoup de gens voient une ancienne interface qui fonctionne encore et pensent que « compatibilité » signifie qu’elle fonctionnera indéfiniment. Mais la documentation liste aussi trois anciennes routes raccourcies, désormais dépréciées, qui seront supprimées à l’avenir.
Je le vois en deux parties.
La première concerne la vérification de version. Un client n’a pas besoin d’attendre que l’interface change puis de découvrir un problème. Il peut indiquer au nœud à l’avance quelle version de Rusk il accepte. La vérification stricte est utile car il vaut mieux rejeter clairement une requête plutôt que de laisser un ancien client recevoir des données qu’il pourrait comprendre incorrectement.
La deuxième concerne la migration des routes. Les nouvelles intégrations doivent utiliser /graphql pour les requêtes de chaîne, bloc, transaction, mempool et archive. Les méthodes de contrat doivent passer à /on/contracts/.... Les anciennes routes ne sont prévues que pour la période de transition.
Cela compte aussi pour les utilisateurs normaux. Les dépôts sur les exchanges, les soldes des wallets et l’historique du navigateur dépendent tous du fait que les clients comprennent correctement les données du nœud.
Pour $DUSK , je pense que la maturité ne consiste pas seulement à garder la chaîne en ligne. Cela signifie aussi que les wallets, les exchanges et les indexeurs suivent les changements d’interface.
La vraie question est : les clients grand public migreront-ils avant la suppression des anciennes routes, ou seulement après que les utilisateurs commencent à voir des échecs ?
#dusk $DUSK
Beaucoup de gens voient une ancienne interface qui fonctionne encore et pensent que « compatibilité » signifie qu’elle fonctionnera indéfiniment. Mais la documentation liste aussi trois anciennes routes raccourcies, désormais dépréciées, qui seront supprimées à l’avenir.
Je le vois en deux parties.
La première concerne la vérification de version. Un client n’a pas besoin d’attendre que l’interface change puis de découvrir un problème. Il peut indiquer au nœud à l’avance quelle version de Rusk il accepte. La vérification stricte est utile car il vaut mieux rejeter clairement une requête plutôt que de laisser un ancien client recevoir des données qu’il pourrait comprendre incorrectement.
La deuxième concerne la migration des routes. Les nouvelles intégrations doivent utiliser /graphql pour les requêtes de chaîne, bloc, transaction, mempool et archive. Les méthodes de contrat doivent passer à /on/contracts/.... Les anciennes routes ne sont prévues que pour la période de transition.
Cela compte aussi pour les utilisateurs normaux. Les dépôts sur les exchanges, les soldes des wallets et l’historique du navigateur dépendent tous du fait que les clients comprennent correctement les données du nœud.
Pour $DUSK , je pense que la maturité ne consiste pas seulement à garder la chaîne en ligne. Cela signifie aussi que les wallets, les exchanges et les indexeurs suivent les changements d’interface.
La vraie question est : les clients grand public migreront-ils avant la suppression des anciennes routes, ou seulement après que les utilisateurs commencent à voir des échecs ?
#dusk $DUSK