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

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" ?

Reply via email to