Twitter, your "since_id" feature has been broken since October 2009, and it is STILL broken. And yet you warn us that not using it will result in blacklisting? Your search API is unreliable when since_id is used. Someone at Twitter mistakenly closed the bug in December but oh yes, it still exists, it still gets plenty of comments. Fix that before requiring it to be used. Unacceptable.
http://code.google.com/p/twitter-api/issues/detail?id=1154 On May 27, 3:12 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > Hi Developers, > > A few quick points before I go into more detail: > > * For the Search API, you should *only* be > usinghttp://search.twitter.comtoexecute search requests. > *Not*http://api.twitter.com/1/searchor any other variation. > > * *Next week*, we plan to remove the erroneous, unsupported endpoint > athttp://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 > athttp://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 ishttp://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 usinghttp://twitter.com/search,http://api.twitter.com/search, > orhttp://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 thehttp://api.twitter.comor > 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 athttp://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 > athttp://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 > athttps://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, Twitterhttp://twitter.com/episod
