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?

Reply via email to