Thanks Chad, that's what I was afraid of. I wonder if you know about this next question:
Twitter API docs say search is rate limited to something more than REST which is 150 requests per hour, but for the sake of argument let's say the search rate limit is actually 150 hits per hour ... Since I have to do 15 consecutive searches to make sure I've retrieved the last 1500 matching items, does this mean I can only do 10 sets of 15 searches per hour = 150 request per hour? If so, this is only one set of searches every 6 minutes, and it seems to me that on a trending topic there might be lots more than 1500 new tweets every 6 minutes. How can I get around this limit? I'm not trying to hurt Twitter, but business applications that require ALL tweets to be recorded cannot deal with these types of limitations on a practical basis, and if Twitter doesn't come up with a better way I can see this hindering its future revenue streams from businesses like mine that want to build on a solid and easy-to-use foundation. So getting back to my question of "What do I do now" ... Do I have to put my automated search code on a bunch of separate servers so the IP's are spread around -- such that none of them hit the limit of 150 searches per hour? Seems to me that this is the only realistic way to insure that I can always retrieve all the matching results I need without hitting the API limits ... but if you or others have a better suggestion please let me know, thanks. On Jul 9, 5:52 pm, Chad Etzel <jazzyc...@gmail.com> wrote: > Yep, you gotta do 15 requests at 100 rpp each. > -Chad > > On Thu, Jul 9, 2009 at 5:45 PM, owkaye<owk...@gmail.com> wrote: > > > I'm building an app that uses the atom search API to retrieve recent > > posts which contain a specific keyword. The API docs say: > > > "Clients may request up to 1,500 statuses via the page and rpp > > parameters for the search method." > > > But this 1500 hits per search cannot be done in a single request > > because of the "rpp" limit. Instead I have to perform 15 sequential > > requests in order to get only 100 items returned on each page ... for > > a total of 1500 items. > > > This is certainly a good way to increase the server load, since 15 > > connections at 100 results each takes far more server resources than 1 > > connection returring all 1500 results. Therefore I'm wondering if I'm > > misunderstanding something here, or if this is really the only way I > > can get the maximum of 1500 items via atom search?
