The short answer is convenience for developers. In most cases showing information about a tweet isn't enough -- it needs to be augmented with user data. Rather than require a separate call to retrieve that user data (or building a cache of user object data on the client side) we provide that data inline for all statuses.
In places like home_timeline and friends_timeline this inclusion of full user objects is extremely useful, and from an efficiency standpoint probably not too bad in the common case. In the case of something like user_timeline it is inefficient. There are three solutions here 1) Never populate user objects 2) Sometimes populate user objects 3) Always populate user objects We've decided on 3 as the best blend of usefulness and efficiency for now. In the future we may revisit providing more compact forms of this data. ---Mark http://twitter.com/mccv On Tue, Mar 16, 2010 at 5:32 PM, MaDeuce <kheaus...@gmail.com> wrote: > Twitter newb question: > > Mark, I want to be clear that I'm not questioning the accuracy of your > answer at all; I'm sure you're correct. However, I can't fathom why > there would be this much redundancy in the data returned by the > Twitter API. If I understand correctly, if I get the 20 most recent > status posted by a user, then that user's data will be returned 20 > times - one with each returned status. > > Ed's original reply sounded plausible (and interesting), as it at > least provided a reason for the repeated inclusion of user objects, > inefficient though it might have been. > > Even a basic normalization would include just the id in the status as > opposed to the entire user object. I have to assume that the user is > there for a reason, however it's one that I can't figure out. Can you > or someone else educate me about why this data is present? > > Thanks very much, > Kenneth > > On Mar 15, 3:48 pm, Mark McBride <mmcbr...@twitter.com> wrote: > > This is incorrect. The user object returned with a status is intended to > be > > represent the current user object, not a historical one. However. There > > are currently several bugs open around this, so the user object currently > > represents a snapshot of the user some time in the fairly recent past. > > > > ---Mark > > > > http://twitter.com/mccv > > > > On Mon, Mar 15, 2010 at 1:04 PM, M. Edward (Ed) Borasky < > zzn...@gmail.com>wrote: > > > > > > > > > Yep ... but you don't get all of their tweets. You get the most recent > 3200 > > > of their *original* tweets. If they used the built-in retweet, those > > > retweets won't show up in the pages. Try it on @znmeb (me), who > > > built-in-retweets a lot. ;-) > > > -- > > > M. Edward (Ed) Borasky > > > borasky-research.net/m-edward-ed-borasky/ > > > > > "A mathematician is a device for turning coffee into theorems." ~ Paul > > > Erd?s > > > > > Quoting Raymond Camden <rcam...@gmail.com>: > > > > > Hmm. So if the API for getting a user's tweets allows you to get _all_ > > >> of them (via paging, not in one request), that would be a way to trend > > >> their data over time, right? > > > > >> I'd rather not use twitalyzer - I want to use the Twitter API natively > > >> if I can. > > > > >> On Mar 15, 2:01 pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> > wrote: > > > > >>> Well, you can retrieve the user's most recent tweets via > > >>> statuses/user_timeline. Each returned tweet will have a "created_at" > > >>> date/time stamp and an embedded "user" object. Inside this embedded > > >>> user object will be the number of friends and followers the user had > > >>> when the tweet was created. Plot the date/time stamps on the X axis > > >>> and the friends on the Y axis and do a kernel regression. ;-) > > > > >>> Or, you could go to twitalyzer.com, key in the user's Twitter screen > > >>> name, then use the "Trends" menu item to display the user's metrics. > ;-) > > >>> -- > > >>> M. Edward (Ed) Borasky > > >>> borasky-research.net/m-edward-ed-borasky/ > > > > >>> "A mathematician is a device for turning coffee into theorems." ~ > Paul > > >>> Erd?s > > > > >>> Quoting Raymond Camden <rcam...@gmail.com>: > > > > >>> > Is it possible to get information about a user based on a certain > > >>> > time? For example, the number of friends for an account can easily > be > > >>> > returned - but it is for the time of the call itself. Is there a > way > > >>> > to get those values from arbitrary date times? >