Re: [twitter-dev] tweet id versus idStr
They aren't different. JavaScript can't handle large numbers (I think the limit was at 53 bits) so there's an id_str as well, to avoid this issue. In JavaScript, always use id_str. Tom On 6/7/11 10:28 AM, Christian Rishøj wrote: (Reposting from the twitter-anywhere-dev group.) In an @Anywhere application we are building at http://tweetshow.nu/ we would like to use the (as of yet unofficial and unsupported) in-browser object-oriented wrappers for the REST API for marking statuses as favourites. However, there seems to be some confusion with respect to the ids in the generated requests. Specifically, when we call someStatus.favourite() in our application, we see this (failed) request: • Request URL: https://api.twitter.com/1/favorites/create/77973769376894980.json • Request Method: POST • Status Code: 404 Not Found On the other hand, if we favourite the same status directly at http://twitter.com/, we see this request: • Request URL: http://api.twitter.com/1/favorites/create/77973769376894976.json • Request Method: POST • Status Code: 200 OK Notice that the ids don't match, even though it's the same status. Inspecting the status object, I noticed that both ids occur: • attributes: Object • contributors: null • coordinates: null • created_at: Tue Jun 07 05:42:49 + 2011 • favorited: false • geo: null • id: 77973769376894980 • id_str: 77973769376894976 • in_reply_to_screen_name: null • in_reply_to_status_id: null • in_reply_to_status_id_str: null It leaves me wondering: Why is id different from idStr? Why does the @Anywhere API seem to use the wrong attribute in generating the request? Any hints would be much appreciated. Best regards Christian -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] tweet id versus idStr
When I inspect the objects returned by @Anywhere, id and id_str are consistently different. Some examples: id: 78578304315179000 id_str: 78578304315179009 id: 78574658827460600 id_str: 78574658827460608 The IDs being used at twitter.com seem to be those of id_str. But why then is @Anywhere erroneously using the id when calling e.g. favourite() ? Christian On Jun 8, 2011, at 3:39 PM, Tom van der Woerdt wrote: They aren't different. JavaScript can't handle large numbers (I think the limit was at 53 bits) so there's an id_str as well, to avoid this issue. In JavaScript, always use id_str. Tom On 6/7/11 10:28 AM, Christian Rishøj wrote: (Reposting from the twitter-anywhere-dev group.) In an @Anywhere application we are building at http://tweetshow.nu/ we would like to use the (as of yet unofficial and unsupported) in-browser object-oriented wrappers for the REST API for marking statuses as favourites. However, there seems to be some confusion with respect to the ids in the generated requests. Specifically, when we call someStatus.favourite() in our application, we see this (failed) request: • Request URL: https://api.twitter.com/1/favorites/create/77973769376894980.json • Request Method: POST • Status Code: 404 Not Found On the other hand, if we favourite the same status directly at http://twitter.com/, we see this request: • Request URL: http://api.twitter.com/1/favorites/create/77973769376894976.json • Request Method: POST • Status Code: 200 OK Notice that the ids don't match, even though it's the same status. Inspecting the status object, I noticed that both ids occur: • attributes: Object • contributors: null • coordinates: null • created_at: Tue Jun 07 05:42:49 + 2011 • favorited: false • geo: null • id: 77973769376894980 • id_str: 77973769376894976 • in_reply_to_screen_name: null • in_reply_to_status_id: null • in_reply_to_status_id_str: null It leaves me wondering: Why is id different from idStr? Why does the @Anywhere API seem to use the wrong attribute in generating the request? Any hints would be much appreciated. Best regards Christian -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] tweet id versus idStr
@Anywhere is just another javascript application - it shouldn't use id. Of course, when you inspect the object returned by @Anywhere you'll get the wrong values as well. Someone from Twitter should look into the favorite() one, it shouldn't be doing that. Tom On 6/8/11 11:52 PM, Christian Rishøj wrote: When I inspect the objects returned by @Anywhere, id and id_str are consistently different. Some examples: id: 78578304315179000 id_str: 78578304315179009 id: 78574658827460600 id_str: 78574658827460608 The IDs being used at twitter.com seem to be those of id_str. But why then is @Anywhere erroneously using the id when calling e.g. favourite() ? Christian On Jun 8, 2011, at 3:39 PM, Tom van der Woerdt wrote: They aren't different. JavaScript can't handle large numbers (I think the limit was at 53 bits) so there's an id_str as well, to avoid this issue. In JavaScript, always use id_str. Tom On 6/7/11 10:28 AM, Christian Rishøj wrote: (Reposting from the twitter-anywhere-dev group.) In an @Anywhere application we are building at http://tweetshow.nu/ we would like to use the (as of yet unofficial and unsupported) in-browser object-oriented wrappers for the REST API for marking statuses as favourites. However, there seems to be some confusion with respect to the ids in the generated requests. Specifically, when we call someStatus.favourite() in our application, we see this (failed) request: • Request URL: https://api.twitter.com/1/favorites/create/77973769376894980.json • Request Method: POST • Status Code: 404 Not Found On the other hand, if we favourite the same status directly at http://twitter.com/, we see this request: • Request URL: http://api.twitter.com/1/favorites/create/77973769376894976.json • Request Method: POST • Status Code: 200 OK Notice that the ids don't match, even though it's the same status. Inspecting the status object, I noticed that both ids occur: • attributes: Object • contributors: null • coordinates: null • created_at: Tue Jun 07 05:42:49 + 2011 • favorited: false • geo: null • id: 77973769376894980 • id_str: 77973769376894976 • in_reply_to_screen_name: null • in_reply_to_status_id: null • in_reply_to_status_id_str: null It leaves me wondering: Why is id different from idStr? Why does the @Anywhere API seem to use the wrong attribute in generating the request? Any hints would be much appreciated. Best regards Christian -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] tweet id versus idStr
Hi Christian, The act of examining the non-string versions of the integers in an environment that is actively trying to understand the Integer will almost always yield a munged representation of the number. It's like Schrödinger's Cat. We don't actively support the extended featureset of @Anywhere and it may have not been updated to understand the larger integers now used for tweet ids. When using any feature of @Anywhere not explicitly documented on dev.twitter.com, you're in unsupported territory that is susceptible to some more recent complications in the Twitter platform like these larger integers. That said, thanks for the heads up that there are still some cases where we're not using id_str where we should be. Thanks, @episod http://twitter.com/intent/user?screen_name=episod - Taylor Singletary On Wed, Jun 8, 2011 at 2:52 PM, Christian Rishøj christ...@rishoj.netwrote: When I inspect the objects returned by @Anywhere, id and id_str are consistently different. Some examples: id: 78578304315179000 id_str: 78578304315179009 id: 78574658827460600 id_str: 78574658827460608 The IDs being used at twitter.com seem to be those of id_str. But why then is @Anywhere erroneously using the id when calling e.g. favourite() ? Christian On Jun 8, 2011, at 3:39 PM, Tom van der Woerdt wrote: They aren't different. JavaScript can't handle large numbers (I think the limit was at 53 bits) so there's an id_str as well, to avoid this issue. In JavaScript, always use id_str. Tom On 6/7/11 10:28 AM, Christian Rishøj wrote: (Reposting from the twitter-anywhere-dev group.) In an @Anywhere application we are building at http://tweetshow.nu/ we would like to use the (as of yet unofficial and unsupported) in-browser object-oriented wrappers for the REST API for marking statuses as favourites. However, there seems to be some confusion with respect to the ids in the generated requests. Specifically, when we call someStatus.favourite() in our application, we see this (failed) request: • Request URL: https://api.twitter.com/1/favorites/create/77973769376894980.json • Request Method: POST • Status Code: 404 Not Found On the other hand, if we favourite the same status directly at http://twitter.com/, we see this request: • Request URL: http://api.twitter.com/1/favorites/create/77973769376894976.json • Request Method: POST • Status Code: 200 OK Notice that the ids don't match, even though it's the same status. Inspecting the status object, I noticed that both ids occur: • attributes: Object • contributors: null • coordinates: null • created_at: Tue Jun 07 05:42:49 + 2011 • favorited: false • geo: null • id: 77973769376894980 • id_str: 77973769376894976 • in_reply_to_screen_name: null • in_reply_to_status_id: null • in_reply_to_status_id_str: null It leaves me wondering: Why is id different from idStr? Why does the @Anywhere API seem to use the wrong attribute in generating the request? Any hints would be much appreciated. Best regards Christian -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
