Hi Taylor, I've filed a bug report about using since_id with search 6 months ago after my client users complained about empty / no search results:
http://bit.ly/since_id Is this bug fixed already? If not, how can we use since_id with the Search API so that it is giving us some results and not just an empty set? Also, I'm using a proxy for my users from China and have therefore used the user auth'ed version of the Search api (http:// api.twitter.com/1/search...) If I'm switching to search.twitter.com, will I run into API limits for my proxy then? Thanks for any help Ole @ mobileways.de / #Gravity Twitter Client for S60 Symbian -- http://twitter.com/janole On 28 Mai, 00:12, 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
