Google Deprecates SOAP API 240
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."
Re:Don't be evil! (Score:2, Interesting)
So Google is starting to act like a real business? (Score:4, Interesting)
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:Honeymoon is Over? (Score:5, Interesting)
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.
That's unfortunate (Score:5, Interesting)
Google = Hypocritcal (Score:3, Interesting)
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 it's own content it suddenly has a problem. It makes perfect business sense from Google's point of view, but it exposes those who made the decision for the hypocrites that they are. If they pursue this policy I hope the lawsuits that have been filed against them for copyright infringement are successful and that Google is run into the ground.
Re:What about XMLRPC? (Score:5, Interesting)
Re:Honeymoon is Over? (Score:3, Interesting)
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 now get online.
You have it backwards i.e. Google != Hypocritcal (Score:5, Interesting)
Google != web (Score:3, Interesting)
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 (Score:5, Interesting)
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:Honeymoon is Over? (Score:3, Interesting)
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 as SOAP becomes more and more complex it starts to look like CORBA more and more except of course that every implementation is incompatible with every other one.
It's probably because SOAP blows (Score:3, Interesting)
JSON and the like are, on the other hand, reasonable, and also fairly easy on the eyes of us tired old programmers.
Re:Honeymoon is Over? (Score:5, Interesting)
<?xml version="1.0"?>
<methodCall>
<methodName>namespace.getCountryCodeFromAbbr</met
<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
Re:Honeymoon is Over? (Score:3, Interesting)
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.
Re:Honeymoon is Over? (Score:5, Interesting)
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?
I don't understand this... (Score:1, Interesting)
I run wsdl.exe from the command line, build myself a proxy class. Then I just include that in my application and from then on I'm pretty much calling SOAP methods the same way I'd reference any other class.
How can you say it's tedious?
The S Stands for Simple (Score:2, Interesting)
I'm not overly depressed at the decision to get rid of the SOAP API. See: The S Stands for Simple [wanderingbarque.com].
Maybe Google will follow in Yahoo!'s footsteps and implement a REST API now. Maybe.
There's an alternative. (Score:1, Interesting)
Re:What Business Reasons? (Score:3, Interesting)
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 service that had no tie to generating revenue would be at risk.
AJAX API not the same functionality as the SOAP (Score:1, Interesting)