Google no longer actively supporting the SOAP Search API
Manfred
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
and
supports additional features like Video, News, Maps, and Blog search
results.
For developers who are already using the SOAP Search API, we've kept
the
documentation live on this site.
http://code.google.com/apis/soapsearch/index.html
-----------------------------------------------
Does this mean any change ?
Manfred
etting...@gmail.com
why ajax-only? some of us have slow computers and don't like all that
logic shoved in the front-end.
Manfred
> why ajax-only? some of us have slow computers and don't like all that
> logic shoved in the front-end.
effectively in place for a year or more: no active support. This means:
no future enhancements, not even correcting errors, but still supported
"as is" (rated beta) for this API.
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
commercial offerings.
I would like very much to hear from users which use the API in the
sense of a distributed db-system with unmatched performance.
Best regards,
Manfred
dloomer
conduct backend Google searches through a batch process. There is no
UI, web or otherwise. Javascript is not what I want.
I know this doesn't mean I have to start using the AJAX search API
instead, but this is still less than ideal.
etting...@gmail.com
That can be automated as well, which is probably their intention to
stop it.
Manfred
> Manfred wrote:
> > I would like very much to hear from users which use the API in the
> > sense of a distributed db-system with unmatched performance.
> stop it.
SOAP Search API.
Manfred
mahmut....@gmail.com
develop more smart web search and filtering engines and share this
ideas or project with community and google and internet users.
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
ideas.
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...
Manfred yazdi:
dloomer
of searches, one which I pretty much absolutely need Google for, and
the other, which happens to be the query I issue most often, I can
settle for a different search engine. Yahoo has a nice REST-based
search API. If you're not dependent on the rich result sets you get
from Google, Yahoo might be able to help you in some cases.
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
can tell.
Google had (has) the 1000 request-per-day cap on the SOAP search
anyway. I don't see how anyone who wanted to violate the terms of use
in any significant way could have gotten too far with it.
chovy
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.
dloomer
does not use xmlhttprequest. Instead it appears to use on-demand
Javascript.
http://ajaxpatterns.org/On-Demand_Javascript
dloomer
duplicate threads.
Jacob
case make an XML feed for searches, like they have for news. I use
serverside searches for mobile clients who cannot run advanced
JavaScript and thereby are lost in the AJAX craze.
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
different ways.
Tom Stocky
service for people who are already using it. The change is that we're
not accepting new requests for SOAP Search API keys and are no longer
actively supporting it so that we can concentrate our efforts on the
AJAX Search API:
http://code.google.com/apis/ajaxsearch/
Tom Stocky
Product Manager, Google
dloomer
for us but there should theoretically be plenty of developers out there
who are in the same predicament we are, but didn't have the foresight
to get a developer key before that was cut off. Javascript is great
for a front end, but that's about it.
dloomer
from their server code:
http://www.google.com/search?q=mysearch
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.
chovy
Hi Tom,
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.
Anthony Ettinger
Manfred
> 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.
Manfred
chovy
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".
Manfred
> > > 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?
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 ...
Manfred:
> > In any case, this idea is dead by now.
chovy:
> This idea is used on every Google SOAP API application I've
> come across,
this is called selective perception ...
chovy:
> so I dont' know why you think it's "dead".
the user cannot get a new key anymore.
Hope this helps,
Manfred
chovy
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
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.
> 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?
softplus
close to useless for anything more than just a search box - and those
plain-search boxes can be had in lots of variations anyway. Everything
that requires filtering or extracting of information can't be done --
we might as well have a Google search iframe, only the AJAX version
requires certain browser functionality :-(.
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.
John
shankar
Tom,
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
competition ...
Regards,
shankar
chovy
Hi Tom,
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
students.
hpz...@gmail.com
Tom Stocky schrieb:
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...
Manfred
Hi hp,
OT: As my site relies heavily on 16th century German I would be
interested to learn about your approach (mail).
Manfred
dloomer
attention; first off, the Register has run with it and has made some
specific references to this thread:
http://www.theregister.co.uk/2006/12/19/google_axes_soap_api/
In addition, Digg has featured that same article, and as of this moment
there have been 30 comments from users:
http://www.theregister.co.uk/2006/12/19/google_axes_soap_api/
The "Google Blogoscoped" blog has also covered it and received 24 user
comments:
http://blog.outer-court.com/archive/2006-12-18-n73.html
A lot of people care about this...
dloomer
http://digg.com/tech_news/Google_quietly_axes_search_API
Manfred
I would like to answer to your last response, because I think
the problem is of interest to many developers. First a short
sumary:
chovy:
> > > > > 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.
Manfred:
> > > > How could the user know for sure what the application will do
> > > > with his key ?
chovy:
> > > Not sure I follow your logic here, how can you be sure of anything when
> > > you use an application written by someone else?
Manfred:
> > 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 ...
chovy responded:
> 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
rights.
This includes laws and proprietary rights in the United States as well
as in other countries."
http://code.google.com/apis/soapsearch/api_terms.html
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
legal, proper and in accordance with these Terms of Use and any
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;"
http://code.google.com/apis/ajaxsearch/terms.html
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
Google.
Best regards,
Manfred
anup.k...@gmail.com
There is a problem of only using AJAX going forward: accessibility of
web sites.
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
JavaScript.
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
this content.
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.
Anup
canixs
Manfred wrote:
> etting...@gmail.com wrote:
> > why ajax-only? some of us have slow computers and don't like all that
> > logic shoved in the front-end.
> It's not "ajax-only", it only makes a policy official, which was
> effectively in place for a year or more: no active support. This means:
> no future enhancements, not even correcting errors, but still supported
> "as is" (rated beta) for this API.
>
> 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
> commercial offerings.
>
> I would like very much to hear from users which use the API in the
> sense of a distributed db-system with unmatched performance.
>
>
> Manfred
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.
themaster...@gmail.com
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?
Manfred
> hpz...@gmail.com wrote:
> 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?
Manfred