Are you all aware of this bug?
http://code.google.com/p/twitter-api/issues/detail?id=1154

We can't reliably use since_id for searches until this is fixed.


On May 27, 6: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

Reply via email to