ePirat,
Ahh, of course. I misinterpreted both the OP requirements and the intention of those fields. I’ve never actually used those ones in particular (through REST or search API), so wasn’t aware of the connection to the authenticating user.
However given that, as a work around, this would still allow you to make less secondary requests to the REST API to see if the authenticating user had retweeted/favorited them. As if those values are zero, then no one, including the authenticating user will have retweeted/faved them, so you don’t need to check them. Also given the ability to bulk lookup of statuses (up to 100 at a time) this could mean as little as one more API request to work around this problem. Just a bit more code complexity.
I can now understand why this functionality is difficult to implement in the search API. Because it is one big generic index (suitable for any authenticating user), it would be relatively resource intensive, and slow down responses from the search API, if they had to do secondary lookups for every returned tweet against the authenticating user, to fill in fields such as these. The data even though retrieved by an authenticating user is equivalent to that an anonymous user might get (if they could). It is perhaps a similar reason also why protected tweets aren’t indexed, because there is no secondary filtering/update of the data based upon the authenticating user.
Cheers,
JB.
