If you're using Twitter's Search API via the api.twitter.com sub-domain, you have a week to switch to search.twitter.com, according to a post from Twitter's Taylor Singletary. The endpoint being removed has not been officially supported by Twitter, though other supported calls use the same sub-domain.
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.
It's important to note that Twitter is not taking away any functionality from its API. It is merely making clear what could be potentially confusing to developers. Twitter's main API for authenticated commands, such as fetching timeline data and creating new tweets, will continue to be operational on api.twitter.com. The change only affects developers using the search API from the unsupported sub-domain. The confusion could have come when Twitter moved to a versioned API, because the search API is not versioned.
Singletary also had some good developer tips for making the best use of the 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
The Search API is bound to put significant stress on Twitter's servers. That's likely the biggest reason for having search on its own sub-domain. Engineers are able to have search servers tuned to its specific needs, without needing to support the authenticated calls.