This project has moved and is read-only. For the latest updates, please go here.

Using the Streaming API vs Status API

May 10, 2013 at 12:07 PM
Edited May 10, 2013 at 12:09 PM
I have been using LinqToTwitter simply to get the lastest 3 tweets for a user in the following way:

_twitterContext.Status.Where(x => x.Type == StatusType.User && x.ScreenName == screenName && x.Count == numberOfTweets);

but have run into a problem where the rate limit is occasionally being exceeded. I read the following page and will consider caching so that I don't have to make any repeated calls for user's Tweets.

The page also suggests using the Streaming API, would this be more appropriate for an application that will make frequent calls for various users' Tweets?

Could anyone give me a code example of how I might do the equivalent call above using the streaming API and explain the differences between the calls as the Twitter documentation is not entirely clear to me.
May 10, 2013 at 2:58 PM

There are samples for the streaming APIs in the downloadable source code.

May 10, 2013 at 3:30 PM
Hi Joe,

It appears that my code example above makes 3 calls to Twitter each time I run the code. I am requesting 2 Tweets per user, so would that be 2 calls for each Tweet plus a an auth call?

So I think that works out that if that code is run more than 60 times in 15 minutes (3 calls X 60 =180) then I break the limit, which is quite feasible if I have even half a dozen users on my website. The code is run each time a user's profile page is visited.

I am new to Twitter but I don't think the streaming/search API is appropriate for getting 2 of any given user's Tweets, each time a profile page is visited (please correct me if I'm wrong), have you got any advice how I can avoid the rate limit, aside from caching?
May 10, 2013 at 5:40 PM
I think you're on the right track. It's best to cache the results to avoid the rate limits. Also, the rate limit applies to the individual user. If you have each user authenticate and then save their credentials, then you can re-use their credentials each time they visit the page.

May 13, 2013 at 11:21 AM
Edited May 13, 2013 at 11:22 AM
Hi Joe,

I have changed my app to use application only auth but am still confused by the rate limit. With application auth, the limit of 300 appears to be for all users of my website. I.e. if I visit a profile page and make the all to Twitter on two different machines, the limit drops to 298. Is that right? What if I had 300 users online I could easily go over the limit?

Also, I have found that IsAuthorized always returns false for my ApplicationOnlyAuthorizer. How can I know if my authorizer is already authorized? I have found that LinqToTwitter throws an unhandled exception if I call Authorize() on every call to Twitter, if I repeatedly do it a lot of times.

I have been storing an IsAuthorized bool in Session, but then the Session vallue could outlive the actual authorization itself.

Thanks a lot for all your help.

P.S. I realized that I have to be careful with lazy loading and linq, as it could repeatedly make the same call to Twitter if it is lazy loaded. Calling ToList() seemed to solve that problem for me.
May 13, 2013 at 6:49 PM

Correct, application only rate limits apply to your application account, not to users. The situation is worse than 300 users because if any number of users made a significant number of requests, you would easily exceed your rate limit in 15 minutes.

IsAuthorized isn't implemented for ApplicationOnly yet. Essentially, IsAuthorized only checks to see if you have tokens loaded, but doesn't communicate with Twitter. I implemented this intentionally so that I don't cause you to incur unnecessary rate limit charges that you aren't aware of. For the user-centered authorizers, there's a VerifyCredentials query on the Account entity you can use.