As of December 5, 2006, we are no longer actively supporting the
SOAP Search API. We encourage you to use the AJAX Search API instead.
The AJAX Search API is better suited for search-based web applications
supports additional features like Video, News, Maps, and Blog search
For developers who are already using the SOAP Search API, we've kept
documentation live on this site.
Does this mean any change ?
why ajax-only? some of us have slow computers and don't like all that
logic shoved in the front-end.
One problem for Google might have been that most of the applications
which are using it, are variants of SEO services and are very close to
I would like very much to hear from users which use the API in the
sense of a distributed db-system with unmatched performance.
I know this doesn't mean I have to start using the AJAX search API
instead, but this is still less than ideal.
That can be automated as well, which is probably their intention to
I have began write small programs via search api, and I am planning to
add a new layer of my queries before send to search engine. I try to
this a couple of weeks, and have some very intersting solutions and
I have trusted in Google, and suppose it continue to support me.
I think "ajax and search" is not suitable for apply my ideas, because,
search intelligence is not a just user interface problem...
I don't think I quite understand the point about "automating" searches.
Why is this bad? I think the whole point is, whether you conduct your
searches from the backend or a web frontend, do you violate the terms
of use or not (namely, using it for commercial purposes is a
violation). A frontend (AJAX) search could conceivably violate these
terms, just as a backend (SOAP) one could. My searches are certainly
"automated" by my definition -- isn't most code "automated?" -- but
nothing that Google would have any problem with whatsoever, as far as I
Google had (has) the 1000 request-per-day cap on the SOAP search
in any significant way could have gotten too far with it.
AJAX only can query the local server to get it's responses from, so I'm
guessing that the SOAP/WSDL API will still work.
On a slightly more selfserving note my site uses AdSense. Since AdSense
is not clever enough to change when content changes using AJAX I find
it useful to perform searches on the server and thereby present a more
static page, but one that gives better AdSense results - especially
since users don't really perform many searches at a time.
In any case I don't see the need to completely cut off the serverside
of it. As with geocoding for the map API the data can be presented in
Product Manager, Google
and then wrote a wrapper to convert the response HTML to the same (or
similar) XML returned by the SOAP API?
My guess is that this would be a no-no, but just want to confirm.
Thanks for responding. I am working on a application that requires SOAP
API, so if I let people use it, then only those with existing SOAP keys
can use it. I know of several applications that do the same, requiring
the user to get their own API key.
How could the user know for sure what the application will do
with his key ? In any case, this idea is dead by now.
Not sure I follow your logic here, how can you be sure of anything when
you use an application written by someone else? This idea is used on
every Google SOAP API application I've come across, so I dont' know why
you think it's "dead".
> > In any case, this idea is dead by now.
> This idea is used on every Google SOAP API application I've
> come across,
this is called selective perception ...
> so I dont' know why you think it's "dead".
the user cannot get a new key anymore.
Hope this helps,
Thanks for your input Manfred. I take it that it's against ToS to give
someone else your API key, even if their app required it. I am unsure
how Google would hold someone "responsible" for it. What possible harm
could happen, other than hitting your 1,000 limit for the day? It isn't
like a password, because a password could be used to gain access to
All the api key does it let someone query Google - unless of course I
can be identified by my API key, or my Google account compromised,
which I am unaware of as being a possibility.
> this is called selective perception ...
...if that makes you feel better, sure I'm ok with being "selective".
As I said, I've only concentrated on seo-related api tools, the
majority of which after becoming popular either shutdown or switch to
this model unless they want to only server 1,000 requests a day. I
asked google for an increase awhile back and was denied, as I'm sure
others were as well. The only choice to continue then would be to store
peoples' API key...am I correct?
How long will the SOAP API remain online?
This is effectively pushing those developers who spent a lot of time
and effort working to make more out of Googles search either to
competitors or towards breaking the ToS: collecting + selling API keys
(already seen that), scraping web-search (seen that) and maybe even
scraping the AJAX API results (possible, but probably unnecessary). Sad
Google, what is your suggestion: what should the developers of those
tools do now? Going to AJAX is not a solution for us.
I read the shift as being one that discourages the development of any
server based value add over google search and encourages the
development of browser based value add to google search.
To me this is a severe restriction on the types of value one can build
- but then maybe that is the intent here - google wants less
Thanks for responding in this thread.
I'm in the same boat as Shankar. Although I haven't looked at the AJAX
documentation, I'm inferring that any app I write would have to be
AJAXed based...thus limiting to browser use only. Not to mention
significantly increasing my development time for cross-browser
compatibility and slowing down the user experience. Especially if they
aren't using a modern PC loaded with RAM and a fast processor.
Why not at least make it worthwhile for anyone spending the time and
effort and remove the non-commercial stipulation? We're not all college
Thats bad news for anybody using the soap API for doing natural
language processing research like named entity recognition, ontology
learning, web-as-corpus etc...
OT: As my site relies heavily on 16th century German I would be
interested to learn about your approach (mail).
In addition, Digg has featured that same article, and as of this moment
there have been 30 comments from users:
The "Google Blogoscoped" blog has also covered it and received 24 user
A lot of people care about this...
I would like to answer to your last response, because I think
the problem is of interest to many developers. First a short
> > > > > I am working on a application that requires SOAP API, so if I let
> > > > > people use it, then only those with existing SOAP keys can use it.
> > > > How could the user know for sure what the application will do
> > > > with his key ?
> > > Not sure I follow your logic here, how can you be sure of anything when
> > > you use an application written by someone else?
> > For most web-based applications the user is _not_ required to supply
> > personal information. But in this case the user got a _key_ for
> > personal use only because of an agreement between him and Google.
> > He is bound by the "Terms and Conditions" and can be held accountable
> > for it (he might be identified by Google with the key). It's very
> > similar to giving away your password ...
> Thanks for your input Manfred. I take it that it's against ToS
> to give someone else your API key, even if their app required it.
> I am unsure how Google would hold someone "responsible" for it.
The ToS do not explicit mention this, but I would think it is against
the spirit of the ToS to give the key to a third party. The uncertainty
about Googles reaction seems intentional to me.
Now for the main argument:
> What possible harm could happen, other than hitting your 1,000
> limit for the day? It isn't like a password, because a password
> could be used to gain access to privileged information.
> All the api key does it let someone query Google - unless of course I
> can be identified by my API key, or my Google account compromised,
> which I am unaware of as being a possibility.
Your key (which is bound to your Google account) would enable a
third party to act in your name and this was the reason for
comparing the key with a password. If the third party acts unlawful,
this might have heavy legal consequences for _you_!
>From the ToS:
"Furthermore, you may not use Google SOAP Search API in any manner
that either directly or indirectly violates any laws or proprietary
This includes laws and proprietary rights in the United States as well
as in other countries."
The ToS for the AJAX Search API are newer and more explicit by
listing 16 examples from which I'll quote the first two:
"You agree to use the Service only for purposes that are
applicable policies or guidelines. By way of example, and not as a
limitation, You agree that when using the Service, You will not,
and will not permit your end users or other third parties to:
- defame, abuse, harass, stalk, threaten or otherwise violate the
legal rights (such as rights of privacy and publicity) of others;
- upload, post, email or transmit or otherwise make available any
inappropriate, defamatory, infringing, obscene, or unlawful Content;"
Note: The third party may not even have accepted the ToS in
case it relies exclusively on keys from others. In case of an
organized crime it might be difficult to localize and pin down
anyone except the owner of the key.
There are other questions too: If you are providing a service
based on the API, how can make transparent to your users
what you are going to do with the users input? A phony statement
will not do and some cases will need also additional support from
There is a problem of only using AJAX going forward: accessibility of
In may countries, such as UK, all web sites must be accessible, not
just federal sites. Many people therefore use the WCAG 1.0 Guidelines
(2.0 is in the works, but problematic). One of the most basic
accessibility guidelines is that content should not be *dependent* on
Also, guidelines aside, most screen readers can't deal with content
changes very well.
Please consider allowing new SOAP Search API keys to be available (I
was about to sign up!!) so that sites can remain accessible and use
I have a question too: why is the AJAX search being made so prominent
that other methods (SOAP) are not longer being offered to new
customers? Is it so you have tighter control over the output? Is that
for "branding" purposes?
The "look" of your search results aside, the quality of the HTML output
is awful, from an accessibility perspective, and some of us would be
interested in using SOAP so that we can present the results to our
users in a more accessible, but just as good looking (or better, even)
on the screen for those who are not completely blind.
Google went ajax on their apis with the intention of stuffing their
sponsor ads in the results where with SOAP api currently do no include
ads and is not possible because API user can filtered them out. I
think google ajax api is a big joke. I build my own ajax api similar
to google using yahoo data and provide more customization such as more
results and pagination which current google ajax doesn't have. You can
check out my current running ajax running website at
http://video.canixs.com where more google video search results and
pagination is available. Soon an Yahoo Ajax version simliar to google
ajax apis will be available for any API user are interesting.
Crap. I'm making an IRC bot that requires a SOAP API key to Google up
search info. How else am I supposed to make my PIRCBot work with this?