Why doesn't Twitter payload include only string ID?

Question

Why doesn't Twitter deprecate the integer IDs and keep only the string IDs? Currently Twitter API payloads include both kinds of IDs and unnecessarily bloat the size. Since the documentation doesn't mark the integer IDs as candidates for future deprecation, I assume they plan to keep both kinds of IDs for an indefinite period. I'm puzzled as to why.

Here are some example fields I'm talking about: id, in_reply_to_status_id, in_reply_to_user_id, quoted_status_id.

I understand why Twitter had to include the string IDs in the first place ( here's why ). My question is why they keep including the integer IDs.

Answer 1

Javascript cannot support numbers with >53bits.

While JS can't support long numbers doesn't mean other ones can't. If you don't mine the data straight on a website you're able to use the integer value of the string.

It also comes down to maintaining consistency. The authorized resellers of the tweets and many larger companies have used that information (int ID), and have established years of information based off of that. Removing it instead of adding to it would cause issues that effects many individuals outside of twitter.

In the end, the long integer effected only a small number of languages not a large portion, nor all of them. There is no specific reason to remove it.