tweet id versus idStr

[Christian Rishøj]

In the @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:
How 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