Ninjamonk, I second what you are asking for here: a search API addition to allow ids as valid queries.
In my code, I represent users by their static ids rather than their screen_names but when doing a search I have to convert back. It would be nice to have the flexability to do search through both user id and user screen name. Does anyone else see a need here? @dougw On Feb 6, 6:16 am, Ninjamonk <dar...@stuartmedia.co.uk> wrote: > 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 <a...@twitter.com> 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<a...@twitter.com> 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<jstrell...@urltrends.com> wrote: > > > >>>> Thanks Alex, > > > >>>> I too, would like to see this return userids AND usernames. > > > >>>> -Joel > > > >>>> On Feb 3, 5:01 pm, Alex Payne<a...@twitter.com> 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
