[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
No, frankly, I didn't put 2 and 2 together on the piece of info you're looking for; the XML aspect of your subject confuses focus. Well, sorry about that ... it's referred to as the xml format in all of the API docs, and it has no DTD or XSD schema to infer a better name from. so that's how i referred to it -- for future reference, is there some other name people use to refer to that format option on this list? in-memory. That scenario has simply never been a problem for me. A minor amount of additional work and resources required, but the server-side business-centric apps I work with have a lot of state to begin with. I wouldn't mind seeing full XML info available in the search API, but it doesn't seem like much of a stretch to separately retrieve and cache that sort of info either. I have no problem maintaining state, i am happily maintaining all the state and history i can about the user est i'm interested in -- and i'd even be willing to maintain state about every tweet ever to twtiter that refers to one those users by name ... if there was an easy way to get that info. But fetching each of those tweet individually seems ridiculous and prohibitive, especially since all my app cares about is tweets that are replies -- there's no way to filter on that type of information using the search API, so most of the individual tweets i have to retrieve (one at a time) don't even have the data neccessary to make them worth maintaining state about. your example of caching user data is one thing: it's trivial to cache all the metadata about a finite set of users, but you can't cache tweets that haven't happened yet.
[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
On Sep 4, 4:43 pm, Andrew Badera and...@badera.us wrote: ATOM _is_ XML ... not sure what the problem is? Uh, yes ... at a basic level that's true -- but the fact that you would point that out suggests that you aren't remotely familiar with the various response formats twitter API calls. Let me explain what little i do know... Twitter supports 4 output formats (that i know of): json, atom, rss, and a twitter specific xml schema. In the documentation for every api method, there is a Formats section that lists which formats are supported for that API call and they are refered to as json, atom, rss, and xml ... you pick the format you want by specifying the format as the extension on your rest call. Here is an example of an API that supports all three formats... http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-public_timeline http://twitter.com/statuses/public_timeline.xml http://twitter.com/statuses/public_timeline.atom http://twitter.com/statuses/public_timeline.rss http://twitter.com/statuses/public_timeline.json ...all of these URLs return the same objects, but in different formats -- and as you can see, when you specify the xml formats you get a *lot* more details about each of the status objects then when using the atom or rss formats. My question was regarding the fact that since the search api doesn't support xml (as you can see in the Formats section of the docs: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search) I don't see any way to get the in_reply_to information, without fetching each individual status message returned. (And yes: the search api does support the json format, and the json format *usually* includes the in_reply_to info, but not when using the search API) Now does my question make more sense to you?
[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
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, Hosshoss...@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 ?