Hi Developers, A few quick points before I go into more detail:
* For the Search API, you should *only* be using http://search.twitter.comto execute search requests. *Not* http://api.twitter.com/1/search or any other variation. * *Next week*, we plan to remove the erroneous, unsupported endpoint at http://api.twitter.com/1/search * All REST requests to the API should use the fully qualified hostname and API version in URLs: http://api.twitter.com/1/* -- no other version is valid at this time. * All OAuth negotiation steps should be over SSL and also at http://api.twitter.com -- but without a version. * Don't execute the same search query more often than every 20s and always use since_id on subsequent requests * Consider the streaming API if you're relying on search heavily to power your application *The Long-winded Approach* * * The only endpoint you should be using for search operations in the Twitter API today is http://search.twitter.com -- it doesn't require user authentication or OAuth -- simply identify yourself with a user-agent that is unique to your application. For those using http://twitter.com/search, http://api.twitter.com/search, or http://api.twitter.com/1/search -- you've been doing it wrong :) Though we should have rejected traffic to that end point long ago to avoid confusion, it was never intended as a valid resource for search queries. Next week, we'll be properly closing off this end point to avoid further confusion. If you have code today that uses the http://api.twitter.com or http:/twitter.com domains to execute search requests, be sure and update your code for the proper end point. You can find the Search API documentation at http://bit.ly/twitter-search-api Many users of the Search API are better served by using the Streaming API. If you use the search API to track the tweets of specific users, hashtags, or simple keyword queries, it is highly recommended that you use the Streaming API instead. You shouldn't issue the same request to the search API more frequently than once every 20 seconds -- if you issue the same query more frequently than that, you're in danger of getting blacklisted. In addition, if you find yourself repeating the same query frequently, be sure and make use of the since_id parameter on subsequent requests -- without it, you put undue stress on the search infrastructure and will also be in danger of blacklisting. While we're on the topic of using the proper endpoints, a general reminder about endpoints with the Twitter API: All REST resource requests, with the exception of Search, should be pointed at http://api.twitter.com/1/* -- always use the api subdomain and specify the version number ("1"). No other version number will be accepted for the API at this time and your requests will fail if you provide a different string or integer. All OAuth negotiation steps should be over SSL at https://api.twitter.com/oauth/* (" https://api.twitter.com/oauth/request_token";, " https://api.twitter.com/oauth/authorize";, " https://api.twitter.com/oauth/access_token";, " https://api.twitter.com/oauth/authenticate";) Let us know if you have any concerns about the removal of the unofficial/unsupported search end point. We don't want to break people, but we also don't want you using unofficial API calls with substandard and unpredictable responses. Thanks! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
