Background... I'm attempting to build an app that can display a "conversation graph" of all the tweets to/from people in a small group ... the use case being a set of friends, or coworkers in an office all wanting a quick view of the various public tweets and public reply tweets posted by other people in the group -- along with the full context of those tweets: tweets they are in reply to, or replies to those tweets, even if they are from people not included in the group.
Current Approach... The /statuses/user_status REST API makes it trivial to get public tweets *by* a set of known individuals and using the XML format i can immediately inspect the "in_reply_to_status_id" element to see if there is a "parent" status i should fetch using /statuses/show to fetch the previous tweets for context context on the conversation -- even those tweets were from "outside users" not in the group. The next step is to find public statuses posted *from* outside users in reply to tweets by users who *are*in my set. The "to" param of the / search API makes it fairly easy to find a super set of these messages, but there's just one catch... The Problem... The /search API only supports the "atom" and "json" formats; since it doesn't support the "xml" format option, the only way (i can see) to determine if an item returned by /search is an actual reply to a previous tweet (and not just a shout out) is to fetch each individual tweet using the /status/show API ... but that feels like a very hackish solution, requiring numerous REST fetches of tweets (one at a time using the /statuses/show) just to backfill one additional property. In an ideal world the /search API would support the xml format so "in_reply_to_status_id" was included in the response, and things that weren't a reply could be easily excluded. (even better: if there was an optional param on the /search API that would allow you to restrict the results to only tweets that were replies) Alternately: it would be really great if the /statuses/mentions API (which does support the xml format) didn't require authentication, and allowed clients to pass a screen_name param to fetch public tweets mentioning a specific user. The Question... Obviously, my comments above constitute a suggested change to the existing APIs, but does anyone see any solutions to the problem i describe that would be less kludgy then using the /statuses/show API to fetch *every* individual item returned by the /search API in order to get the "in_reply_to_status_id" ?