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.
> 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.
ettingerka...@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.
Without getting into details (my uses are respectable though), I 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.
Manfred wrote: > ettingerka...@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 wrote: > ettingerka...@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.
> Best regards,
> Manfred
That can be automated as well, which is probably their intention to stop it.
ettingerka...@gmail.com wrote: > 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. > That can be automated as well, which is probably their intention to > stop it.
I did not get your point (_That_ ?) as I was speaking about the SOAP Search API.
I've thought the google aimed to encourge the developer, about to 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...
> 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.
I've kinda solved my problem. In my case I need to conduct two types 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.
mahmut.esit...@gmail.com wrote: > I've thought the google aimed to encourge the developer, about to > 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: > > >From Google:
> > 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.
dloomer wrote: > I've kinda solved my problem. In my case I need to conduct two types > 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.
> mahmut.esit...@gmail.com wrote: > > I've thought the google aimed to encourge the developer, about to > > 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: > > > >From Google:
> > > 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.
chovy wrote: > dloomer wrote: > > I've kinda solved my problem. In my case I need to conduct two types > > 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.
> > mahmut.esit...@gmail.com wrote: > > > I've thought the google aimed to encourge the developer, about to > > > 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: > > > > >From Google:
> > > > 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.
I think Google should continue development of the SOAP API, or in any 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.
Just to clarify, we're not planning to shut off the SOAP Search API 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/
For reasons that several people have outlined, that's all well and good 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.
Tom Stocky wrote: > Just to clarify, we're not planning to shut off the SOAP Search API > 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 wrote: > Just to clarify, we're not planning to shut off the SOAP Search API > 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 wrote: > Just to clarify, we're not planning to shut off the SOAP Search API > 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
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.
chovy (Anthony Ettinger) wrote: > 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 wrote: > chovy (Anthony Ettinger) wrote: > > 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
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".
> > > 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?
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 ...
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,
Manfred wrote: > 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? > 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 ...
> 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
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?
I just want to add that I'm disappointed about this decision. AJAX is 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.
Tom Stocky wrote: > Just to clarify, we're not planning to shut off the SOAP Search API > 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
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 ...
shankar wrote: > Tom Stocky wrote: > > Just to clarify, we're not planning to shut off the SOAP Search API > > 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
> 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
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.
> Just to clarify, we're not planning to shut off the SOAP Search API > 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
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...
> > Just to clarify, we're not planning to shut off the SOAP Search API > > 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
> 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...
Hi hp,
OT: As my site relies heavily on 16th century German I would be interested to learn about your approach (mail).
