Can we get clarification on the since_id issue? You have warned us
that not using since_id will get us blacklisted, and at the same time
since_id appears to still be broken according to others on this list.
Please advise.

What I do is request 100 responses per page, and then manually check
each tweet against the most recent tweet_id I've received for this
query. I stop asking for more pages when I reach a tweet that I
already have. Is this acceptable, or is since_id working now?

On Fri, May 28, 2010 at 1:41 AM, janole <s...@mobileways.de> wrote:
> 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

Reply via email to