Passer au contenu principal
Chaque objet dans X — un Tweet, un message privé, un utilisateur, une List, etc. — possède un identifiant unique. Au tout début de la plateforme, ces identifiants étaient des nombres suffisamment petits pour être générés séquentiellement. Avec le temps, pour accompagner la croissance, on est passé de 32 bits à 64 bits. Aujourd’hui, les identifiants X sont des entiers non signés uniques sur 64 bits, basés sur le temps plutôt que séquentiels. L’identifiant complet est composé d’un horodatage, d’un numéro de worker et d’un numéro de séquence. X a développé un service interne appelé « Snowflake » afin de générer ces identifiants de manière fiable et uniforme (en savoir plus sur le blog X). Des nombres aussi grands que 64 bits peuvent poser des problèmes avec des langages de programmation qui représentent les entiers sur moins de 64 bits. C’est le cas, par exemple, de JavaScript, où les entiers sont limités à 53 bits. Pour contourner ce problème, dans les conceptions initiales de la X API (v1/1.1), les valeurs d’identifiant étaient renvoyées sous deux formats : à la fois en entiers et en chaînes de caractères.
{"id": 10765432100123456789, "id_str": "10765432100123456789"}
Si vous exécutez la commande (10765432100123456789).toString() dans la console JavaScript d’un navigateur, le résultat sera "10765432100123458000" : l’entier 64 bits perd en précision en raison de la conversion (ce que l’on appelle parfois « munging », une modification destructive d’une donnée). Dans les X API jusqu’à la version 1.1, vous devez toujours utiliser la représentation du nombre sous forme de chaîne afin d’éviter toute perte de précision. Dans les versions plus récentes de l’API, toutes les grandes valeurs entières sont, par défaut, représentées sous forme de chaînes.
I