sorry badly put, I meant via user id, search via user id so like FROM: 342342342 etc returns the same as say FROM: ninjamonk.
On Feb 5, 10:49 pm, Alex Payne <[email protected]> wrote: > You can presently look up usernames in the Search API. What in > particular are you looking for? > > > > Ninjamonk wrote: > > Hey Alex, any chance of adding a way of looking up the user name to > > the search api instead then? > > > On Feb 5, 6:19 pm, Alex Payne<[email protected]> wrote: > > >> The reason why we can provide the list of IDs without any pagination is > >> that it comes directly from our denormalized list data store, and > >> requires no joining, either in SQL or at the application layer. As soon > >> as we pull in data like screen_name that's sitting elsewhere in our > >> architecture, the response time slows down drastically. > > >> So while I do understand that it'd be more convenient, my hunch is that > >> the quality of service for such a method would be intolerable. > > >> dougw wrote: > > >>> For all those wanting id AND username attributes to be returned with > >>> these new methods, be sure to head over to > >>>http://code.google.com/p/twitter-api/issues/detail?id=265andvote > >>> (click the star) to signal your support. > > >>> @dougw > > >>> On Feb 5, 11:40 am, jstrellner<[email protected]> wrote: > > >>>> Thanks Alex, > > >>>> I too, would like to see this return userids AND usernames. > > >>>> -Joel > > >>>> On Feb 3, 5:01 pm, Alex Payne<[email protected]> wrote: > > >>>>> Happy to announce two new API methods today, delivered in response to > >>>>> developer demand for an easier way to keep tabs on users' social graphs. > >>>>> The methods, /friends/ids and /followers/ids, return the entire list of > >>>>> numeric user IDs for a user's set of followed and following users, > >>>>> respectively. Responses to these methods are cached until the user's > >>>>> social graph changes. The responses come direct from our denormalized > >>>>> list data stores, and should be reasonably fast even for users with a > >>>>> large number of followers/follows. > > >>>>> These new methods are most useful for services that are maintaining a > >>>>> cache of user details. If you see a user ID that you don't have cached, > >>>>> you'll have to call /users/show to retrieve that user's details. But for > >>>>> services with large user bases, or those that simply want to diff a > >>>>> user's social graph over time, we hope these methods will come in handy. > > >>>>> You can find the documentation > >>>>> athttp://apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. > > >>>>> -- > >>>>> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > >> -- > >> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
