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."

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?

[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...

No money in it... Exactly. But there is a way

[iendedi]

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

This is eactly it. Google has a revenue model based on ads, this API is in direct competition with their business. From a financial perspective, it doesn't really make sense for google to allow unrestricted access to their API.

But that is key and I hope Google understands this: The risk is from unrestricted access.

It is somewhat easy to implement XML security and provide approved businesses with what amo

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/ [ebay.com]

Re:

[jimbojw]

There is an eBay API.

Ah, but can I buy a Google API Key on eBay now that they're not being given away? Preliminary searches indicate 'no'.

Re:

[Anonymous Coward]

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

But people do. Why does everything we do have to be dictated by what a company would do? There are ways to achieve things in life other than to wait for a company to do it.

Re:

[TeXMaster]

But people do. Why does everything we do have to be dictated by what a company would do? There are ways to achieve things in life other than to wait for a company to do it. Yes, like doing it yourself. Provided you have the resources (money, time, etc) to do it, of course. Which is, may I suggest, rarely the case.

Re:

[TeXMaster]

Ahem. sorry for the misformatting, got a little too hasty. My reply was:

Yes, like doing it yourself. Provided you have the resources (money, time, etc) to do it, of course. Which is, may I suggest, rarely the case.

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:

[Afecks]

Web service standards cannot be driven by the very people who profit most from non-standard solutions.

Who else has more of a reason to put forth the time, effort and money to do it?

Re:

[DrEasy]

Don't know about the money part, but why not the IETF?

Re:

[rs79]

"Don't know about the money part, but why not the IETF?"

They only do protocols.

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:

[LizardKing]

What you're describing - an interface in a C like syntax - is exactly what CORBA IDL provides. While CORBA has its own set of problems, it is a far better solution than SOAP. SOAP is incredibly tedious to develop for, and difficult to optimise as it's predicated on XML parsing which is an inefficient format for what is essentially an RPC mechanism.

Wild idea:

[hummassa]

OR ... just use JSON instead of XML? But I know, there are a lot of security implications...

Re:

[tonigonenstein]

I hope you do realize that you are not supposed to manipulated the wire protocol directly, be it xml, IIOP or something else. In the case of SOAP there are libraries that let you programmaticaly create a message. But if you have a WSDL that describes the service (similar in intent to CORBA's IDL), and most service provider give you that, you can use libraries that create a proxy object from the WSDL. Then you can call native methods directly on the proxy.
In your exemple that would be something like

proxy

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:

[tonigonenstein]

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?

No you're not. The sad thing is that before the invention of XML there already was a great standard for this: ASN.1, which is widely used in the telecommunication industry. ASN.1 allows one to represent hierarchical information, just like XML, but its advantage is that it defines several

Re:

[maraist]

because not everybody uses javascript in their peer applications. And many of us need to use wealth of tools and languages to communicate (use the right tool for each job). so using established inter-company communication formats is critical. Building on those tools for the personal hobyist allows rapid integration into the larger ecosystem. It is fine to us propritary technologies in point to point communication (A la AJAX), but API's like eBay, Google, credit card, and thousands of middleware compani

Re:

[marcosdumay]

That one of the very few cases where XML does make sense. If you look better at that , all you can take out of it is syntax sugar, no intrisical complexity (you just replace a mess of tags with a mess of braces). That at the cost of implementing another parser that will often be full of bugs.

Re:

[cyngus]

No, everything has to be XML to be understood by humans and machines. If I'm just looking at the response {"John Smith", 34, 'M'} from the server, what does this information mean? If its in XML I can skim the structure that the values are returned in and know what these values are. With just three pieces of data returned, this doesn't mean much, but what if my data structure has hundreds of values returned? Or what if ten integers are returned, I'm going to easily confuse whether the piece of data I want is

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...

Re:

[killjoe]

"Thinking about the traditional and dirty way to do the same thing: write scripts to 'post' webpages and extract the return pages."

That's so cute, "the traditional way". Soap is just another in the long line of technologies that attempt at RPC. SOAP is actually a way to make CORBA more palletable. CORBA was universally despised for it's complexity so SOAP was supposed to simplify it. The only way to make RPC simple is to neuter it so that's what they did. Alas there was a reason for all that complexity and

Google = Hypocritcal

[Luscious868]

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.

Which makes Google one hell of a hypocritical company. This is a company that couldn't exist if it wasn't for content put out there by other businesses and individuals yet when it comes to sharing

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.

Re:

[dave562]

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

That's not exactly true. In a lot of markets there is value to giving outside vendors access to your internal data. For example, one of my clients sells their product through Home Depot and Expo Design Centers. HD and Expo are constantly calling my client for status updates. By putting that information on the web my client saves a lot of time because their people aren't tied up answering calls for information that HD reps can

Re:

[Phillip2]

Yes, you're clearly right. Companies are not going to be interested
in semantic web and web services. And without companies, then nothing
is ever going to work.

Contrast this with the experiences of the web. In the very early days,
companies were just leaping on board, using it very early, providing
large quantities of usable content with advertising attached.

Any idea that it scientists putting their papers and biogs online,
musicians building up hoards of guitar tabs and thousands of trekies
explaining the full d

Re:

[SeaFox]

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

That's the point, it says lather, rinse, repeat right on the bottle. If you follow the directions, SOAP is gentle enough for baby's skin. Keep out of eyes, though.

Re:

[MemoryDragon]

Soap is too complex yes, but I do not agree with the assumption you do not a tool = good, tool = bad, we have been relying on tools since the first assemblers, after all an assembler also is a tool to generate 0 and 1 or at an higher level hex codes, which people used to program directly. What the soap tools do, is just to generate the glue code instead of having it done implicitely by a library trying to cover the general remoting complexities generally. That soap shoots over the top with its crude xml b

Power of SOAP

[Phil John]

The real power of SOAP comes when you are using a language or framework that has support for it builtin. SOAP is complex simply because it does more than XML-RPC with type handling etc.

In PHP you can use NuSOAP (or in 5.x the built-in SOAP library), to simply register some functions and autogenerate the WSDL, or generate a proxy from a given WSDL - takes a couple of minutes tops and then looks like you are simply calling another function.

Anyone who uses ASP.NET regularly has it even better - create an ASMX file, define a class and functions like you would in any C# class, add some namespace arguments, a [WebMethod] over all your public methods and it can then be instantiated and called from any other ASP.NET website or .NET dekstop app seamlessly, like it was a local class. It's really cool just how transparent it all is. You can even throw exceptions and catch them on the other side, pass back objects - it's really slick.

Re:

[fireboy1919]

The real flaw of SOAP comes out when you are using a language that has SOAP support built-in. It makes you think that you can write cross-platform web services with it, when in reality, you can only write them for your language/platform of choice.

Your example shows exactly how this is true.

While SOAP has types built-in, the only collections supported by all platforms are arrays of primitives, which means that you have to write serializers for any collection types (such as, for example, HashMaps/Associative

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

bastards

[PktLoss]

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

Re:bastards

[Sentry21]

He's not kidding [amazon.com] - it's a good book too, I'd highly recommend it if you're doing web programming.

Re:

[clickclickdrone]

Not sure why you got trolled - seems a useful post to me - thanks. Unlike one of the Amazon reviewers who clearly bought the wrong book - duh.

Well it was 'just' a Beta

[rednip]

Well it was 'just' a Beta, but then again so is gmail, Google maps, and every other neat Google application. Of course as a gmail user it does give me pause, as to what I'm really doing.

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 [wikipedia.org]

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?

[BrynM]

Does Google offer XMLRPC services?

The AJAX API [google.com] might be what you're looking for.

Re:

[rainman_bc]

The AJAX API [google.com] might be what you're looking for.

That's a client-side lib. What if you want to make the call from a server?

Re:

[Bob of Dole]

You write your own damn search engine :)

Re:What about XMLRPC?

[BrynM]

There's also the Data API [google.com].

Re:

[rjshields]

after many, many hours spent working through the confusing and pointless code google created to throw hackers off we finally worked out the url to get search data:

Why didn't you just use ethereal and be done in 5 minutes?

Oh! Come On.

[camperdave]

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

Come on... Cleaner than SOAP? What could be cleaner than SOAP?

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.

Re:

[mr_zorg]

But that's what libraries like Apache Axis are for. I don't have to deal with it. For me, it's a snap. I send objects, I get objects. Easy. But write SOAP from scratch? Hell no!

Tooling is the wrong solution to SOAP

[vdboor]

But that's what libraries like Apache Axis are for. I don't have to deal with it. For me, it's a snap. I send objects, I get objects. Easy. But write SOAP from scratch? Hell no!

That's a solution to a problem that shouldn't have existed in the first place.

It reminds me of a SOAP is simple conversation [wanderingbarque.com], which explains quite well how SOAP evolved.

Writing a complex specification makes it hard for other parties to create compatible applications. Just like everybody needs *the one true browser* to navigate ar

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.

Did you mean...?

[DECS]

Google: _SOAP___

Did you mean: _soup?_

Don't be evil!

[hernick]

Wow. This is the first time I read an article about Google and, for a second, find myself thinking "Google appears to be Evil and driven by Greed. This isn't happening. This is just a mistake. Google will see the light. Google is Good."

Re:Don't be evil!

[Ingolfke]

Yes. Google is evil. They've become drunk on their stock earnings and intend to use their massive computing capabilities to use up all of the Earth's energy in order to enslave mankind... it's all clear now that the SOAP Search API is gone.

Um... seriously though. Give them a bit of time and see if the make and announcement and publish an alternative (non-AJAX) API.

Re:Don't be evil!

[FooAtWFU]

It needn't even be "non-AJAX". There are plenty of other possibilities for a web service API besides SOAP. The one I'm particularly well-acquainted with, and perhaps the biggest contender out there, is REST (REpresentational State Transfer). In particular, I recall one web developer howto-type site speaking about Amazon's SOAP-related services, and how most people don't use them, because they're an order of magnitude slower than most REST services.

Re:

[Ingolfke]

REST is great! It's easy to use... I've used Amazon's REST API and liked it a lot.

Re:

[Baricom]

I think I understand the point behind REST (it follows the existing semantics of HTTP - GET means GET and POST means POST, and URLs are nouns, right?), but I do have a complaint: the return type for a given REST call varies from service to service; you need to write a parser to handle different kinds of XML coming from each REST API. In contrast, XML-RPC is dirt-simple for a developer: make a method call using syntax that resembles the programming language you're working in, and get back data in the approp

Re:

[Anonymous Coward]

That could be what they're intending, but the larger lesson of OP's post still stands. Companies exist to make profits for their owners, and large publicly held companies are under massive pressure to show increasing revenues and profits on a quarter by quarter basis. Plus, the senior employees get greedy and self-satisfied. Microsoft was once regarded as a courageous little band of corporate misfits taking on the IBMs of the world. Sun's Java was once seen as the salvation of the software industry. De

Re:

[dircha]

"Wow. This is the first time I read an article about Google and, for a second, find myself thinking "Google appears to be Evil and driven by Greed. This isn't happening. This is just a mistake. Google will see the light. Google is Good.""

Google provides you a wide range of services, which you value, at aboslutely no cost to yourself.

?

*boggle*

So did you just need to take a break from bashing the Salvation Army, or what?

Uncleanliness is next to Satanliness

[Anonymous Coward]

Without soap Google will become evil.

Re:

[freemywrld]

Without soap, google will become a hippy.

(SOAP is a WS) != (WS is SOAP)

[MrData]

Simpy put the Author of the article has it all wrong. SOAP is a type of Web Service but not all web services use SOAP.

Re:

[Shados]

Indeed, however, for the time being, SOAP is the most useful way to use web services when you don't know the clients. I mean, yeah you could use JSON, but then it is definately not as easy to interoperate (a lot of legacy environments don't even support document mode and you're forced to use RPC, and thats with SOAP....nevermind less mainstream ones).

So it is still a big hit in that sense. Not that I'd cry if SOAP was replaced by something else...

Google branding?

[BorgCopyeditor]

So, skimming the Google AJAX Search API [google.com] 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?

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...)

Re:

[BorgCopyeditor]

I happen to agree. I think I inadvertently tossed some flamebait out there. A better question would be whether people will be put off using this service on their websites by the branding.

The Bigger Question is...

[SerpentMage]

I think the bigger question is why Google is not able to make money any other way? Seriously, let's say that the SOAP API makes oodles of money, then well, Google would not be deprecating it. Google is a company that wants to make money. And it seems the new way of implementing a search is the only way Google can make money. AND THAT is the interesting thing. They have lots and lots of smart people who, it seems, are having a hard time making money outside of the original idea that spawned Google.

loss, opportunity, lesson or deja-vu?

[siddesu]

Yawn... Google is a company. Regardless of the marketing bullshit they spew on, they aren't in the business of providing APIs (or whatever), they are in the business of making money. Anything else is subject to change.

Their responsibility is more towards their shareholders, not so much towards their users. So, if they think one of their products -- be that APIs, ajax apps or whatever are providing diminishing returns for some reason, they'll axe it unless it is popular enough so that too many users feel ripped off. APIs aren't in the category at all.

Also, the bigger they get, the more expensive the stock becomes, and the more their ownership sreads, the more clout the bean counters have over any other management ideology.

So, if one relies exclusively to Google for anything, better check your contract with Google carefully and assess all risks (including risk from expensive litigation) first.

Re:

[Anonymous MadCoe]

You are right, but I have found that hard to expalin to people. Any company is about making money (especially public companies). This means they are out there to find profit, not promote certain standards or ways of thinking.

So once any company becomes dominant in any marketplace they will focus less on open standards but solely on what's good for their business.

No one can argue that keeping SOAP would make them potentially a lot of money, but I'm sure they did the math...

Re:

[rjshields]

Suppose there is a dead person on the street. Will you search his pockets and take his money under the assumption that "this serves the interests of the shareholders"? ... See. There is ethics.

I'm sorry but how exactly does withdrawal of a SOAP API equal mugging dead people in moral terms? That is a seriously fucked up analogy to make and I shall have to conclude that you are not of sound judgment and ignore your views along with the rest of the foaming idiots!

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 [google.com], their own embedded search example is showing a blog posting titled "Google quietly backrooms SOAP API for AJAX".

Screenshot here [davidmays.com] (Yeah, I'm using IE7, wannafightaboutit?)

Re:

[YGingras]

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.

Come on, it was only a toy. With only 1000 query a day (or was it even less) you can't build anything usefull with it. I tried it, it was fun but when I want to do datamining (what else would you want the API for?) I parse the HTML. They let you hammer the thing p

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:

[simscitizen]

MS live search has a SOAP, Yahoo search has REST--maybe you could use those instead.

And the replacement

[brajesh]

The recommended replacement AJAX api [google.com] not only has limited applications, but also it promises [google.com] to show google ads beside the results.

Not that Google Search API has ever been very stable - it probably works only 80% of the time. Now even the support has been dropped and usage samples along with FAQ have been removed for SOAP api.

Obligatory questions/puns

[SeaFox]

• Does Google own any patent/copyright on SOAP? If Google is dropping SOAP I don't want to get fucked if I pick it up.
  
  
• No! Please don't let us run out of SOAP, Google! I feel so dirty using Microsoft's rival technology!
  
  
• This is quite a slippery situation. I hope Google will come clean on my they are depreciating the APIs.
  
  
• My reaction to this required me to use some SOAP - on my clothes.
  
  
• When the developers heard this we had to get some SOAP - for their mouths.
  
  
• I guess the "do no evil" bubble has finally burst...
  
  
• There must be a better solution that will allow the technology to continue while satisfying Google's business reasons. No reason to throw out the baby with the bath water...
  
  
• Why does Google have to play dirty like this?
  
  
• This doesn't smell like an Irish Spring to me!
  
  
• Hopefully they will introduce something even better for us to use, then the whole issue will be a wash.
  

Fight Club

[Lethyos]

Tyler Durden says: use SOAP?

Google != web

[suv4x4]

Not many were the people that appreciated SOAP before "Google did it" (tm).

After "Google did it" (tm), SOAP is suddenly a good thing. Now that they drop it, peple are discussing if it's again a bad thing. Google is not the whole of Internet though. People will use SOAP if it's better than other solutions for a given tasks.

And if it isn't, then it was a fad all along.

Same with "AJAX" by the way. JavaScript was out there for years before "Google did it" (tm) but there were not many people appreciating it. If Google drops JavaScript tomorrow, would this spell the end of AJAX?

Same logic applies.

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?

Re:

[grimJester]

The Ajax API is not a replacement. It probably lets you do what Google intended users to do with the SOAP API (embed their search into your web page), but it's not a "build anything you want on top"-style interface.

Re:

[jalefkowit]

Google is replacing SOAP with an AJAX API.

No they're not. There is an "AJAX API", but it isn't really a replacement for the old SOAP API in any meaningful sense. I posted an explanation why [wordpress.com] on Scripting News yesterday. Basically, the AJAX "API" is just a blob of Javascript that returns HTML in response to a form POST -- HTML that includes advertisements -- and you're obligated by the Terms of Use to display that HTML unmodified. That's very different from the SOAP API, which returned raw data you could

Drop-In Replacement Already Available

[feste12]

There's already a drop-in replacement [evilapi.com] 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.

SOAP Was Always An Eye Test

[LifesABeach]

IMHO, I always thought SOAP was over engineered. Simple Web Service's are like a console program, but the input is in field form from the web, with input type checking. Output is an XML string with an embedded "xml-stylesheet" statement, (for the unwashed) [w3.org]. The security of a simple Web Service is; Simple. A Simple Web Service already has many locked doors to slow down uninvited guests, and the other doors that the uninvited enter can be easily closed. This act from Google will reduce their maintenance co

It's probably because SOAP blows

[joe_n_bloe]

Any serializing transport where, ultimately, figuring out what is going wrong - in normal use - involves using a packet sniffer to dump XML, is just broken. Nevermind that XML was never intended to be written by humans. Nevermind that the XML used in SOAP isn't intended to be human readable. It's just a layer of unnecessary crap that isn't even interoperable between different languages. Or, for that matter, different implementations on the same platform. "Web services" is a lovely addition that removes the last bit of comprehensibility and connection to reality while adding nothing except gaping security holes.

JSON and the like are, on the other hand, reasonable, and also fairly easy on the eyes of us tired old programmers.

Good riddance.

[arcade]

Seriously. Good riddance. SOAP is a mess. Google has gone the XMLRPC way, and they're providing access via that.

This isn't google being evil. This is google removing a piece of completely unnecessary junk from their offerings. SOAP should never have seen the light of day, and google is now making sure that they do their part of burying it.

What Business Reasons?

[RAMMS+EIN]

Does anyone know what the business reasons mentioned in the scoop would be?

Re:

[DragonWriter]

Presumably, because SOAP doesn't make them any money, where AJAX, with the TOS they have, will, by generating ad views.

The SOAP API was always one of those things everyone should have known would either go away (if it wasn't successful in the right way to create a commercial market, maybe micropayment supported) or become non-free (if it was successful enough). With Google not too long ago announcing that they would be looking at the number of offerings they had, one had to expect that things like the SOAP

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.

What?

[mutube]

Google has an API for Snakes On A Plane? No wonder they're going down the (series of) tubes.

SOAP technology sucks, too

[Nelson Minar]

I leave town for a couple of days and I miss my moment of fame on Slashdot. Ah well. My blog post doesn't exactly argue it's "business reasons rather than technical ones", although my post does dwell on the business reasons too. There are plenty of technical reasons to hate SOAP too. For my view on that, see my blog post about why SOAP sucks [somebits.com]. Bottom line is SOAP is too complex, doesn't work well in practice, and strong typing is the wrong choice for loosely coupled distributed systems.

Re:WTF is SOAP?

[MeanMF]

Spoken like a true Slashdotter... :)

Re:

[jours]

> WTF is SOAP?

Based on the slashdotters I know, you aren't likely to get an answer to this here.

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 [wikipedia.org]

Re:

[Anonymous Coward]

Have we already forgotten about Snakes on a Plane??

Re:

[MillionthMonkey]

...for google's free services. I bet they got a new young hotshot in house that wants to make lots of money (insert greedy pic).

Well, that young Google whippersnapper will ultimately find out the hard way that each of his company's services wants to be free.

Re:

[interiot]

They allegedly watch for robot scraping and will cut off your IP if they detect it... is this not an issue? Or it's not an issue if you keep it to a rate similar to what the SOAP interface allowed?