0
votes

I'm getting results back from the twitter search/tweets api. The problem is I'm trying to recreate a link back to the original tweet...which usually is in the form of:

http://twitter.com/{user.screen_name}/status/{id}

The problem is if something is a Retweet then the user.screen_name breaks the link (404) because a retweet points to the original tweet's id, not id of the tweet that is a retweet (if that makes sense)...so for retweets I need link to be http://twitter.com/{retweeted_user.screen_name}/status/{id}

I cannot see a flag in the response that tells me if an object is a retweet or not since there is no actual "retweet" object.

I'm surprised twitter doesn't actually a simple metadata.source_url or something easily accessible rather than me having to rebuild a link to twitter original tweet page.

2
Use https://twitter.com/statuses/{id} if you do not mind a redirect.pii_ke
Ahh dang, thank you! I tried /status/ and gave up. If yuu make that an answer I'll accept it.chovy

2 Answers

0
votes

Use https://twitter.com/statuses/{id_str} if you do not mind a redirect.

-1
votes

Turns out https://twitter.com/statuses/{id} works fine (thanks @pii_ke)

The problem was that twitter's search api returns both .id and .id_str and something I did not realize was that large numbers don't parse well in javascript.

You can read more about it here: https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake

...but the just of it is that you should always use the .id_str and keep these id numbers as strings.

(90071992547409921).toString() is parsed as '90071992547409920' <-- notice the missing 1 at the end has become a 0?

This was my problem in addition to not knowing about http://twitter.com/statuses/<id_str>

In my case I was using a koa app in node.js on the server side and that was querying twitter's API which somewhere tried to parse that original .id as a string and lost some bits...using .id_str everywhere fixed the problem.