First off, the address for search is currently search.twitter.com i.e. the documentation and the information should use the following url:
http://search.twitter.com/search.json?q=recipe See http://dev.twitter.com/doc/get/search All of your other issues are a result of not using the proper URL. At some point we look to combine the 2 API,, but issues like you have noted will cause this to be painful. Jonathan @twittersearch On Tue, Apr 27, 2010 at 8:45 PM, Adam Green <140...@gmail.com> wrote: > I've found a number of things that don't seem to behave as documented > on either the old API wiki or the new Dev site. I'm writing a tutorial > on this portion of the API, so I'd like to know if the docs are > correct, and I'm just getting weird results, or if the docs are wrong. > I'm using PHP and cURL to test this. I'm sending a very simple search > request of: > http://api.twitter.com/1/search.json?q=recipe > > 1. Docs say "Search API is not limited by the same 150 requests per > hour limit as the REST API. The number is quite a bit higher and we > feel it is both liberal and sufficient for most applications." > > When I try calling the Search API, the rate limit shown in the header > is 150. Exceeding 150 in an hour does cause a rate limit failure, so > this number does seem to be 150. > > 2. Docs say "Consumers using the Search API but failing to include a > User Agent string will receive a lower rate limit." > > I got the same rate limit of 150 whether or not I use the cURL user > agent option. I tried an application name of "twitter app tutorial" > and a standard Mozilla user agent string. > > 3. Docs say "An application that exceeds the rate limitations of the > Search API will receive HTTP 420 response codes to requests." > > When I exceed 150 requests, I get a 400 HTTP response code, not 420. > > 4. Docs say "It is a best practice to watch for this error condition > and honor the Retry-After header that instructs the application when > it is safe to continue." > > When I exceed 150 requests, I don't see a retry-After header value. > > Thanks for your help with this. >
