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 +0000 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
