[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > -----Original Message-----
> > From: Paul Prescod [mailto:paul@prescod.net]
> >
> > I think we can convince Google because providing an HTTP API
> > alongside their SOAP one will decrease costs, not increase
> > them. The HTTP one will become more popular over time and
> > their bandwidth and processing costs will plummet. They can
> > still be 100% buzzword compliant. I'm starting to organize
> > the peasants with the pitchforks:
>
> Can you back those claims up, or talk more about them? As they
> exist already, why would having URL queries increase costs?
Having a URL query would decrease costs. For example they wouldn't have
to Base64-encode data to wrap simple strings in dozens of tags.
> Cool, I'm looking forward to reading it. [The wsdl is 404ing by the
> way; will you mail out when it's up?]
Should be there now.
> But what's the fuss? It's not that hard for Google to return schema
> backed results from the URI query as Dare outlined [I quite like
> the terse tags they use; it makes the XML easier to read].
I agree that it isn't hard. So they should have done it!
The "fuss" is mainly about the fact that the web services hype is in
such overdrive that SOAP is being used for things it is utterly (and
obviously!) unsuited for ... and in my opinion it is quite hard to find
things it is well suited for. It's similar to the fuss about the
side-swinging patent. It is a sign of the times.
> Anyone
> that wants ask by SOAP can have it, anyone that wants ask by URL
> can have it. It's hardly exclusive. It just seems like a special
> case of device transformation.
It's a little more than device transformation -- you're accepting
different *inputs*. But certainly there is no rocket science in
supporting them both. Really, there is no rocket science in the API at
all. They had 95% of it working a year ago using pure XML and HTTP and
there was no big hype about it because it wasn't officially supported
technology.
Paul Prescod
|
