Are all of Google's API's going to be based around SOAP? I was hoping
that there would be a simple URL request format with XML result. This
way the client would not be required to understand SOAP. I'm sure
that the SOAP route has many advantages, but I'd like to keep it as
lightweight as possible on the client side.
Right now, Google's main search page returns HTML:
http://www.google.com/search?hl=en&q=API
I was hoping for something that would return XML using a similar URL
request:
http://www.google.com/searchXML?hl=en&q=API&key=1234567
Chris
> I was hoping for something that would return XML using a similar URL
> request:
> http://www.google.com/searchXML?hl=en&q=API&key=1234567
>
> Chris
Alternatively, it would be nice for the rest of us to have a pure HTTP
API - no funky query terms, just HTTP headers that make sense.
GET http://www.google.com/search?q=xml+router
Accept: text/xml
Accept-Language: en
Authorization: BASIC YZ79S=
I heartily agree. I wrote Google about this and they responded:
"""
Thanks for your input!
We chose to deliver Google Web APIs via SOAP because we believe that
the SOAP developer tools make Google Web APIs accessible to the
broadest developer community. In the future, for developrs who prefer
handling XML directly we may develop a simple GET-based XML interface
or an XML-RPC interface that can also be accessed via a license key.
"""
Perhaps if more people express their interest in a plain GET-based XML
interface, Google will add it.
Yup, you and me both. They actually have this;
http://www.google.com/xml?q=foo
It was public last year, and returned a proprietary XML schema, but it
was neat-o. Far easier to use than SOAP. Unfortunately it's only
available to partners now. 8-(
MB
> Perhaps if more people express their interest in a plain GET-based XML
> interface, Google will add it.
Are you sure you want your app key available as plaintext in a URL?
Nevertheless, it *is* a swell idea. Maybe Google could expose a
subset of functionality to a GET-based interface and allow richer
functions only through an RPC interface.
I was using that as well, which is why it hurts so much now that it is
gone. :)
I had decyphered enough of their cryptic DTD (at least they had a DTD)
to make my own functions to get a category list and reconstruct most
of the Google features in my own application. It was a nice demo
until they pulled the plug. I hope the folks at Google can find a way
to sell this to end users, I know I would certainly be willing to pay
a reasonable fee.
SOAP is a little too thick for me (although I can see why it would be
attractive to many people and why Google would offer it first), I'd
like access to the raw XML results. At least they seem willing to
consider the idea.
Chris
I'm too interested in this.
MfG
Berthold Werner
The Google API uses no features of SOAP that are not more simply and
easily availble through HTTP. As well, I note that their Java
implementation does not even use a SOAP implementation! In other words
they are not even benefiting from the interoperability that SOAP is
supposed to buy them. At heart it is just passing around query
parameters and parsing XML.
Paul Prescod
Having a non-SOAP interface to this would be excellent. I've started
to write code for a Googlebox type app in ASP using SOAP, but, I won't
be able to use it where my website is hosted 'coz they don't support
SOAP. Having a non-SOAP interface would allow me to have it up on my
website.
Paul
perhaps it's possible in some way to take the examples form the file
googleapi.zip from the path \googleapi\soap-samples, modify them and
post them to http://api.google.com/search/beta2 ?
MfG
Berthold Werner
http://www.google.com/google.dtd
Also, doing a Google query with an RDF response would rock. You could
relate "similar pages", "cached", "view as html", "view as text",
"page rank", etc. to each returned URI. The indentation feature where
pages from the same site are grouped together, could also be an
assertion. Heck, all that stuff in the DTD could be associated to the
returned URI with RDF.
But first things first. 8-)
MB
I think as the services explodes and billions of parameters emerge to
control and customized the services, uri trick will not be able to
handle it.
It would be nice, but in the meantime, maybe you could send an HTTP
POST request using the SOAP format? I.e., add a "SOAPAction" HTTP
header to your request and put the body of your request in XML format.
I wouldn't know how to do this in ASP, but in perl it should not be
hard, as most web hosting facilities that offer Perl/CGI support the
perl sockets library. If anyone out there has examples of this, I'd
like to see them. If not, maybe I'll try writing one myself. :)