ATOM _is_ XML ... not sure what the problem is? ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)
On Fri, Sep 4, 2009 at 6:18 PM, Hoss<hoss...@gmail.com> wrote: > > 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" ? > > > > >
