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.

When I've had to cross-correlate between search and main API in the
past, such as pulling search feeds for display elsewhere, and needing
additional user info on the person sending the tweet in said feed, I
pull the search feed ATOM and work against my main XML results
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.

∞ Andy Badera
∞ +1 518-641-1280
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me:"andrew badera") OR ("andy badera")

On Sun, Sep 6, 2009 at 2:40 AM, Hoss<> wrote:
> On Sep 4, 4:43 pm, Andrew Badera <> 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...
> ...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:
> 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