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

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: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]

Re:What about XMLRPC?

[BrynM]

Does Google offer XMLRPC services?

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

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

[Ingolfke]

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

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]

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.

Re:What about XMLRPC?

[BrynM]

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

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.

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.

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.

Re:That's unfortunate

[simscitizen]

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

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

[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 encodings: several binary encodings with different tradeoffs for efficient machine processing, and a text encoding for humans. You choose the best encoding for your application (which you can always change if you want), and you have standard tools to convert between encodings if necessary.
In this exemple, you could use a binary encoding for the wire protocol and a text encoding for the service description (which is normally written by a human). If you wanted to debug the wire communication you could intercept the binary encoding and convert it to the text encoding to present it to a human. Best of both worlds: efficient machine processing and possibility of human inspection if necessary.
Proposals for a binary xml are just attempts to recreate the ASN.1 functionnality of alternate encodings after the fact. Talk about wheel reinvention.

Re:No SOAP, Radio

[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 format and display however you liked.

Another observer hit the nail on the head yesterday: [megginson.com]

An AJAX interface like this is a great thing for a lot of users, from bloggers to small web site operators, because it allows them to add search to their sites with a few lines of JavaScript and markup and no real coding at all; however, the gate has slammed shut and the data is once again locked away outside the reach of anyone who wanted to do anything else.

Re:Power of SOAP

[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 Arrays, Lists, and Sets) that you want to use in *all* the languages you want to make it available to.

Further, not all the implementations support envelopes quite the same, so can't depend on using that technique to send binary data.

These things are, in general, *necessary* to serialize a given object. I'd prefer that you could assign types to these, but you can live without that.

For my money, therefore, XML-RPC is far superior. You get collections (even if they don't have everything you want), and it *works everywhere* (though you do have to Base64 encode your binary data).

It's not perfect, though. For me, the perfect RPC protocol would allow for OOP, and have built in support for these primitives:
date, time, int, long, double, float, byte, byteArray (binary data), type (i.e. an enumerator that indicates one of the existing types), pointer (reference to other parts of the data)
and these collections:
ordered list, unordered list, ordered set, unordered set, and associative arrays (ordered and not)

Of course, just supporting the ordered variety would do the trick. It's easy to ignore an order, after all. You *could* do everything using just the primitives with pointers, but that's *WAY* too difficult for humans to read.

In addition, it would have to have a binary, non XML-mode and an XML mode.

Support for generics and class declarations should also be built in to the interface definition language for this.

That'd be just about exactly what I'd need to use any remote object or function in any language that I use. It seems pretty simple to me, and easy to map into pretty much any programming language.

Anybody know of anything close yet? Despite SOAP's extreme complexity, I don't think that it supports that stuff even now. It just doesn't seem like it should be that hard.

Re:What about XMLRPC?

[Anonymous Coward]

XMLRPC is a good solution for simplistic HTTP client-server architecture request-response needs. It does not provide for identity, authorization, nor authentication. It does not define how to deal with asynchronous request / response, nor encrypted content parts. While its simplicity is enticing, it is also the Achilles Heel.

AJAX API != Web Service API

[PSdiE]

The AJAX API is not a replacement for a Web Service API (SOAP or otherwise).

The AJAX "API" is a customisable, but Google branded search widget. It does not allow programmatic search queries (although it is technically possible to run direct queries to the Web Services powering the AJAX interface, the Google AJAX API T&Cs forbid this).

This is about Google ending programmatic access to its search results, nothing to do with the technical merits/failings of the SOAP technology ("business reasons rather than technical").