Re: New API methods to retrieve social graph without pagination
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 Paynea...@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, jstrellnerjstrell...@urltrends.com wrote: Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Paynea...@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
Re: Feedback for Adobe?
Great. Would be interested to see how much part the Twitter clients have with the download of AIR apps. Non standard windows behaviour on a basic level. Using AIR apps takes me out of my ecosystem. I could are less about cross platform, that is something hindering me promoting any air app. Memory usage - dont know if it is the programming of the app or an air problem. Best practise usages / examples done by twitter or adobe would help the community to build better apps. Supporting that will be helpful for more spread of AIR apps. hth Nicole
Re: Anyone want to write this app?
Follow a few hundred users at once means a few hundred instant api calls. with 20K call cap, I don't think this app will be sustainable unless Twitter removes that cap
Re: New API methods to retrieve social graph without pagination
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 Paynea...@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, jstrellnerjstrell...@urltrends.com wrote: Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Paynea...@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
Re: New API methods to retrieve social graph without pagination
I haven't tried it out yet, but it's exactly what I needed. Thanks! On Feb 3, 8: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
Best practice for building a community website with ~ 20k tweeters?
So I've talked to my boss a bit about this and it appears the upper bound on tweeters that lextweet would end up following is something like 2 - 3 members. The idea of lextweet is not to follow legal posts (so I can't use tagging/etc), but instead to act as a page where lawyers can easily discover other lawyers who tweet -- even if they aren't necessarily tweeting about the law. For instance, some lawyer in Georgia might want to connect to another lawyer in Georgia and then they might both start a conversation about the Hawks or the Falcons. So if I am building an app that tracks the tweets and profiles of that many users, what's the best practice? Right now I have one (whitelisted) user following about 2k ppl so that each time I query twitter I only have to make one request for one timeline, and I only query twitter once a day to update profile info. If I abandoned having this special user to follow ppl, and instead kept the users in a database and queried twitter for each user's timeline that's a LOT more API requests. Are there any of you who own apps of a similar scope and scale? What do you do? What does the Twitter API team recommend? Patrick On Feb 1, 2009, at 5:50 PM, Alex Payne wrote: Whitelisted users can follow a few more users. But we really don't encourage following a ton of people. On Sun, Feb 1, 2009 at 14:38, Patrick Minton patr...@lexblog.com wrote: Does being whitelisted also mean that you can follow more than 2000 people without having 2000 followed? Lextweet.com uses a twitter account to follow members of the legal community and we are rapidly approaching 2000 Patrick -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x Patrick Minton IT Director LexBlog, Inc. +1 206 204 3211
Re: My VPS can't see twitter most of the time.
On Jan 30, 2:09 pm, Alex Payne a...@twitter.com wrote: Chances are good that your IP was blacklisted for excessive traffic. 20k requests per hour is the maximum we accept from any whitelisted IP. Should this clear itself up? The entire service has been mostly offline for over a week, and during a lot of that, google and jabber.org had difficulty communicating, so a large portion of the userbase was offline (thus work wasn't being done for them).
Re: My VPS can't see twitter most of the time.
On Jan 30, 2:09 pm, Alex Payne a...@twitter.com wrote: Chances are good that your IP was blacklisted for excessive traffic. 20k requests per hour is the maximum we accept from any whitelisted IP. Should this ever clear itself up? As far as I can tell, I'm not getting anything in, even though I've reduced my rates and a jabber.org/gtalk problem made large portion of my users unavailable.
Re: My VPS can't see twitter most of the time.
Hi Dustin, Sounds like your IP got blacklisted by our operations team. We've documented what to do in this case: http://apiwiki.twitter.com/FAQ#IsmyIPbannedorblacklisted On Fri, Feb 6, 2009 at 14:15, Dustin dsalli...@gmail.com wrote: On Jan 30, 2:09 pm, Alex Payne a...@twitter.com wrote: Chances are good that your IP was blacklisted for excessive traffic. 20k requests per hour is the maximum we accept from any whitelisted IP. Should this ever clear itself up? As far as I can tell, I'm not getting anything in, even though I've reduced my rates and a jabber.org/gtalk problem made large portion of my users unavailable. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
OAuth Documentation Preview
Hi all, We launched our OAuth code to production yesterday with employee- only access to check for any problems that didn't show up during our testing. We've been running it through it's paces and fully plan to have it open to the closed beta group by next week. If you didn't hear back from Alex and I don't worry, we're working to expand the beta once things are a bit more stable. As part of a company meeting today I presented OAuth to the people who haven't been working on it via a demo app I wrote … it was exciting times to see this run on production. I think of the application developers on this list as an extension of our team so I don't want to wait until next week to send you the documentation. I wrote up a quick how-to sort of thing on the wiki about writing a very simple OAuth app for Ruby on Rals. Check it out at http://bit.ly/api-oauth-ruby. With any luck we can add some more examples and things during this beta period, most notably in PHP since that seems to be the majority of the questions on the list. Thanks; — Matt Sanford
