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?

[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: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?

[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:Honeymoon is Over?

[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 = make_wsdl_proxy ("http://provider.com/service.wsdl");
cc = proxy.getCountryCodeFromAbbr("UK");

And that's it, it cannot be easier than that. Search on the web there are several such libraries available for different languages. If you use a compiled language like C++ you can also compile the WSDL in advance to a proxy.cc/proxy.h client wrapper, much as with an IDL compiler. But in a language like javascript it is better to create the proxy dynamically, and you can also use introspection to discover which methods are available for exemple.

Re:Honeymoon is Over?

[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:Honeymoon is Over?

[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 in slot 5 or slot 6. So, what I'll probably do is build a converter that puts these values in a hashmap (in java) or associative array (in php) or a set of constants to index the return value array (in c[++] or java). Now, if I'm using SOAP, the library probably is going to do this conversion for me, and it can only do that because it can read the XML tags in the response.

With JavaScript most stuff is done with JSON now anyway, so your arguments don't really apply.

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

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.

(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:What about XMLRPC?

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

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: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:Don't be evil!

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

Re:You have it backwards i.e. Google != Hypocritca

[Anonymous Coward]

Strange, when I go to http://maps.google.com/ or use Google earth I sure seem to be viewing content that Google has developer (or paid for) and then _shared_.

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.

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 amounts to an access token. They could also allow developers a limited number of queries per day in the same manner. Such a system would allow Google to allow approved uses of their API (e.g. tools that display their ads or relationships with approved business deals behind them).

Simply letting this wonderful access point into their search engine die would be a grand shame.

Re:Straw Man

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

Wild idea:

[hummassa]

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

Re:No SOAP, Radio

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

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, 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 arround the Internet, everyone needs tools for SOAP. A simple spec would make SOAP extremely powerful, but also sets developers free of certain (commercially available) tools they need now...

In result, this is what SOAP gives us now:

• Implementations that have incompatibilities with each other (e.g. PHP can't send Multiref messages to AXIS because it doesn't detect some optional WSDL property, .Net not being able to parse what PHP sends).
• 5 different styles to communicate. RPC/encoded, RPC/literal, document/encoded, document/literal, "document/literal wrapped". Add Multirefs to the WSDL, and it doubles.
• WSDL being the so generic/abstract it defines methods in three abstraction levels and adds HTTP-bindings as extension feature.
• real-world bindings as extension. "SOAP over SMTP" is called a feature, something nobody will ever use. It's not written with the real/existing world in mind.
• An application layer built on top of an application layer. SOAP implements what HTTP already offers (like error handling and parameter transport).

There is one positive feature I can add. Things like REST have very random return values, SOAP is more consistent here.

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