Google Deprecates SOAP API

Michi writes "Brady Forrest at O'Reilly Radar reports that Google has deprecated their SOAP API; they aren't giving out any new SOAP Search API keys. Nelson Minar (the original author of the Google SOAP API) argues that this move is motivated by business reasons rather than technical ones. Does this mark the beginning of the end for SOAP or for ubiquitous middleware in general?" Forrest's post quotes developer Paul Bausch: "This is such a bad move because the Google API was the canonical example of how web services work. Not only is Google Hacks based on this API, but hundreds of other books and online examples use the Google API to show how to incorporate content from another site into a 3rd party application."

Comments

Honeymoon is Over?

[P(0)(!P(k) P(k 1))]

From TFA:

I remember the first web services summit we did, where a Microsoft developer who I won't name admitted that SOAP was made so complex partly because "we want our tools to read it, not people."

Just as I suspected: SOAP suffers from an artificial (read: gratuitous) complexity; what more do you need besides XML-RPC, anyway?

Google quietly shutting down services, on the other hand, reminds me of differentiating stem-cells: the honeymoon is over.

Re:Honeymoon is Over?

[rbanffy]

Any technology that requires a specific tool to write code for it is way too complex.

Without a Next-Next-Finish wizard, SOAP is a pain. With the tool it's mildly uncomfortable.

Re:Honeymoon is Over?

[timeOday]

This isn't about deprecating SOAP in favor of something simpler, is it? Sounds to me like google wants people to visit their website to use their services. Which, once again, proves why the semantic web and web services will never fly. Companies don't want to make their data and services available to each other.

Re:Honeymoon is Over?

[WasterDave]

Yes indeed it is. The cool kids see externally provided services and say "mashup! mashup! mashup!", the old timers see them and say "risk! risk! risk!".

Dave

Re:Honeymoon is Over?

[Anonymous Coward]

Companies don't want to make their data and services available to each other.

I don't think it's so much that companies don't want to as it is that there is no money in it.

If Amazon provided an API for buying stuff, I think it would stick around

If eBay provided an API for listing / searching, I think it would stick around.

Google, however, provides their product strictly for advertising revenue...it's wayyyy too easy for a consumer of the content to filter out the thing Google makes their money from.

It's very similar to the problem with Tivo's (PVR's) and commercial television. Luckily in that case, the television providers don't make their money directly from advertising revenue...

Re:Honeymoon is Over?

[jsse]

Which, once again, proves why the semantic web and web services will never fly. Companies don't want to make their data and services available to each other.

Well, I beg the differ, please bear with me.

SOAP is based on an idea of giving APIs to external parties for accessing information the way the information-owners want it. SOAP might be bad, but the idea is sound. Thinking about the traditional and dirty way to do the same thing: write scripts to 'post' webpages and extract the return pages. You can imagine slight changes in webpage layout could render the original extraction scripts useless, and that kind of information extraction might not be the owners' desire.

In short, things SHOULD be done this way, but Google doesn't like this implementation(SOAP). Google might want to adopt other implementation, that's what we'd like to know.

Re:Honeymoon is Over?

[jd]

AJAX, SOAP and so on are all based on the premise that there are ways of abstracting out a lot of the complexity of service/user and service/service interactions. That assumption, I believe, is essentially correct. From that premise, these standards go on to assume that vendors are the right people to make such abstractions. Here is where the error lies. Vendors are notorious for producing crippled standards (such as SQL) that require vendor extensions to be usable. At a recent PCI-SIG conference, I was amazed at both the obviously stupid limitations of the standards and the gratuitous "vendor extension" options that very obviously existed so that vendors could provide proprietary solutions to those limitations. If a standard cannot stand, it ceases to be a standard and becomes little more than a cub scout badge.

(Another case: I cannot name a single well-designed W3C spec that was consortium-driven, and cannot name a single consortium-driven W3C spec that was well-designed.)

Web service standards cannot be driven by the very people who profit most from non-standard solutions. Even when they are designed well, they will STILL carry unacceptable flaws precisely because they are not driven by a collective itch but by a desire to stop someone else's scratch being the one that's used. The day a truly open federation of user-developers (you need a group of people where each person is both user AND developer) who have no ulterior motive beyond solving the service issue is formed will be the day that you see a protocol that requires no "perfect case study", proprietary extensions, overweight IDEs, etc. It will just work and be just used. Same as every other system developed that way has always just worked and just been used.

Re:Honeymoon is Over?

[cyclomedia]

What i truly don't understand is why it has to be so complex even the much vaunted and pparently much simpler XML-RPC looks like attatching a nuclear bomb to the process:

<?xml version="1.0"?>
<methodCall>
    <methodName>namespace.getCountryCodeFromAbbr</meth odName>
    <params>
        <param>
                <value><string>UK</string></value>
        </param>
    </params>
</methodCall>

Browsers already have Javascript engines in that take C-syntaxey looking ascii and convert it into functions and objects, so why not just use a C-syntaxey plaintext to describe the service?

read: namespace{ int getCountryCodeFromAbbr( string ); };

send: namespace.getCountryCodeFromAbbr( "UK" );

get : 44

now, ok you might want to send comlext data structures back, but hey, you can just slap in the curly braces and be done

read: namespace{ personStruct{ string name, int age, char sex }; personStruct getPersonFromUserId( int ); };

send: namespace.getPersonFromUserId( 12 );

get : { "John Smith", 34, 'M' };

oh, but i forget: everthing has to be XML to be enterprisey, wether or not it's the best tool for the job, or if there's already a tool for the job that can do it for you with just a little tiny bit of effort. The "include this .js file" AJAX approach is essentially a wrapper for doing what i've just described, but taking the communication automation out of it.

Re:Honeymoon is Over?

[Agelmar]

Have you ever tried using this for nontrivial examples? I must confess to being quite fed up with the whole thing. Support for anything beyond the basics seems to vary greatly from library to library, platform to platform, language to language. Axis is probably the best choice for Java, but it's rather lacking when it comes to commercial support, which is important for some people. For C/C++ you're more or less screwed. Gsoap works (for the most part), but it produces the most god-awful stubs I've ever seen. The library that comes as part of Visual Studio (for .Net I believe) either doesn't support MIME or DIME attachments, I don't recall which. There just seem to be too many problems for me to actually bother to use it.

In my opinion, at this point it's just a mess, and for anything beyond the complexity of the stock-quote example I look to other technologies. I, for one, shed no tears at the end of this honeymoon.

(And am I the only one that cringes at using SOAP messages (or XML in general) for something that's supposed to be a machine-to-machine interaction? If you're going to write a new standard, why not write something more efficient?

Re:Honeymoon is Over?

[awing0]

There is an eBay API. I've used it myself to create a few apps. It's a full featured XML over HTTP interface.

http://developer.ebay.com/common/api/

Re:Honeymoon is Over?

[Kazoo the Clown]

Yes, and where XML really shines is in turning a 1M record database query from 30MB of text into 150MB of text...

bastards

[PktLoss]

Bastards, I wrote one of those books! Quick buy your copy today, it's practicaly a collectable now.

Re:WTF is SOAP?

[MeanMF]

Spoken like a true Slashdotter... :)

What about XMLRPC?

[Dynedain]

Does Google offer XMLRPC services?

If so, then I'd say it's fine to drop SOAP. XMLRPC is a bit cleaner anyways.

Re:What about XMLRPC?

[codepunk]

You sir could not be more correct... We have servers that process tens of thousands of xmlrpc transactions per day and could not be happier with it. SOAP is a absolutley over engineered, complicated pain in the ass spec to deal with. The couple of features it does have over xmlrpc do are not worth the complication of dealing wih it.

Soap, what was that?

[canuck57]

Soap, what was that....

Maybe something to do with:

UNIX Sex

{look;gawk;find;sed;talk;grep;touch;finger;find;fl ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje ct;umount;makeclean; zip;split;done;exit:xargs!!;)}

Re:Soap, what was that?

[corsec67]

{look;gawk;find;sed;talk;grep;touch;finger;find;fl ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje ct;umount;makeclean; zip;split;done;exit:xargs!!;)}

So is that why nerds are getting acused of rape? (Not checking return codes...)
The semicolons should be double ampersands, so that execution will stop if a command fails.

Re:Soap, what was that?

[value_added]

So is that why nerds are getting acused of rape? (Not checking return codes...) The semicolons should be double ampersands, so that execution will stop if a command fails.

Yeah, but in the guy's defense, there wasn't a single argument to any of those commands.

Re:Soap, what was that?

[nacturation]

The semicolons should be double ampersands, so that execution will stop if a command fails. Who said anything about execution? Sounds like you're into some sick kind of sudo masochism.

Re:Soap, what was that?

[NthDegree256]

So is that why nerds are getting acused of rape?

You'd think Google would have paid attention to all those prison horror stories about dropping the SOAP.

Re:Well it was 'just' a Beta

[RuBLed]

...not every other neat Google application. Maps is no longer in Beta as well as Google Earth and some other neat applications.

http://en.wikipedia.org/wiki/List_of_Google_produc ts

Uncleanliness is next to Satanliness

[Anonymous Coward]

Without soap Google will become evil.

So Google is starting to act like a real business?

[dgm3574]

Say it ain't so!

It would be interesting to know how many active API users there were, and at what rate new ones were signing up, if at all. It may well be that continuing to support that API wasn't considered a useful (read: profitable) part of their business.

Google is a publicly held corporation now. They have a responsibility to their shareholders to make decisions based on sound business practices. For a software company that means sending products into the end-of-life bin periodically.

In a fabulous dose of irony, I found that on Google's AJAX Search API page, their own embedded search example is showing a blog posting titled "Google quietly backrooms SOAP API for AJAX".

Screenshot here (Yeah, I'm using IE7, wannafightaboutit?)

Re:Google branding?

[FooAtWFU]

So, skimming the Google AJAX Search API example code pages, it looks like a big part of this is to attach Google's name and image to everything your web page or web app does with the data Google provides. Does that seem to anyone else like a fair assessment? If so, is it a fair practice?

Well, since Google is the one who aggregated it in the first place... and is paying for the processing power and bandwidth requirements that go along with that... what's unfair about the practice? (It's not like they're really preventing one from giving you similar data, or somehow stealing away value from any of the sites they've indexed, or...)

That's unfortunate

[pjdepasq]

I loved using the Google API as the basis of one of my data structures programming assignments. It's a great way to have my student tackle the use of another party's API, as well as a useful way to grab a ton of data and play with it (say in a binary search tree or hash table). Now I need to find something else that will let us do the same, or come up with something else.

Re:WTF is SOAP?

[omeomi]

SOAP (originally Simple Object Access Protocol) is a protocol for exchanging XML-based messages over computer network, normally using HTTP. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on. The original acronym was dropped with Version 1.2 of the standard, which became a W3C Recommendation on June 24, 2003, as it was considered to be misleading. - Wikipedia.org

You have it backwards i.e. Google != Hypocritcal

[theshowmecanuck]

One could argue that if it weren't for Google and other search engines, no one would ever know of about 90% of the web content put out by businesses and individuals. People and businesses who wanted to get *their* word out would have shrivelled up and died on the vine since no-one would ever have heard them calling. Since Google provides a service to those web sites, your argument could be considered spurious and therefore moot. If anything, those web sites owe Google, not the other way around as you contend.

No SOAP, Radio

[Doc Ruby]

How could this deprecation of a SOAP API mark the end of "ubiquitous middleware" (as if that even existed) when deprecation means an API change, not a feature shutdown ?

Google is replacing SOAP with an AJAX API. Maybe it is a blow to SOAP - which is long overdue for the 1990s graveyard. But how could that be bad for open-access middleware when there's a new, better API?

Drop-In Replacement Already Available

[feste12]

There's already a drop-in replacement for applications that are using Google's SOAP API. It scrapes Google's web results and returns them via a SOAP layer. The code behind it is free under the MIT License.

Of course they dropped it...

[MancDiceman]

Correct me if I'm wrong, but the SOAP search results didn't come back with ads embedded in them. The AJAX API tools are capable of putting ad content in their results, as can the maps API because Google is controlling the display elements.

Given that Google want to run their business off the back of ad revenues, it should come as no surprise they're getting rid of services that don't allow them to sell lots and lots of ads. I also imagine that the cost of providing the SOAP interface was higher than any subscription fees would have brought in due to a small market. What's more, it would directly help their competitors pull in results from Google and run their own ads alongside it. The API was neat, but from a business perspective it was always an experiment at best.

Personally, I'd rather they brought something RESTful like Yahoo's interface or xml-rpc to the table, and charged us all a couple of cents per 100 queries, but that isn't going to happen any time soon.