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?

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

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

[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 now get online.

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?

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

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

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?

[DrEasy]

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

Re:Honeymoon is Over?

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

[rs79]

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

They only do protocols.

Re:Honeymoon is Over?

[Anonymous Coward]

Who is John Galt?

Re:Honeymoon is Over?

[Darko8472]

Yes, yes, we know why they don't want to make their data and services available... this is stating the obvious. Spoon feeding not required here.

You must be new here.

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?

[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 binding layer syntax and that things could be and are done simpler is another issue, which inherently came from the fact that lots of parts of soap stem from the roots of Microsoft who basically have an inherent complexity problem when it comes to all things object (see COM/OLE as one of the worst examples of components done wrong)

Re:Honeymoon is Over?

[tonigonenstein]

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

To play the logic nazi, I'd like to point out that the second statement is logically identical to the first. They both say that the intersection of well-designed specs and consortium-driven specs is empty. This is a common mistake.

Re:Honeymoon is Over?

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

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?

[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 companies cant reinvent the wheel every time.

Re:Honeymoon is Over?

[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 details of Picards transporter accident who built
the web from a protocol and markup language into a global repository of
information, knowledge (and confusion) is a total misapprehension, because
it is companies that are responsible for everything.

Phil

Re:Honeymoon is Over?

[Whitemice]

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

This must come from someone who doesn't do any amount of real RPC related work.

"besides XML-RPC"? You've got to be kidding; who about (1) code page management (2) working introspection (3) ***TIME ZONES*** [my goodness how did XML-RPC make it out the door with its crappy time type?] (4) any standardization for authentication (5) complex data types [no, so apps can't live without them].

SOAP is not complicated; creating a SOAP client/server is *MUCH* simpler than creating an XML-RPC client/server if you are using the proper tools.

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?

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

[Anonymous Coward]

Umm... I tried that... trying to type this from the shower, I seem to be stuck, hold on... gott go lather again...

Re:Honeymoon is Over?

[mattpointblank]

Because web designers (who seem to me the majority of the XML-endorsing universe) don't want to look at real code, they like to "simplify" everything into HTML-esque tags. I'm all for semantics when they're neccessary but we call it "code" for a reason.

Re:Honeymoon is Over?

[sukotto]

And then some really cool kid says "Mashup" and "Risk" ... at the same time
(It really was Risk for a while... then Hasbro told him to go fsck himself)

Re:Honeymoon is Over?

[DannyO152]

XML is derived from another well established standard: SGML. It's meant to allow people to define a simple grammar in order to tag data and to separate the information from the presentation in a hierarchical structure called a document. It allows the authors to share with consumers an external mapping document which allows the consumers to assess the validity of the document. A person and a machine may parse the document, and it may be easier for the person who, with superior pattern processing facilities, can separate the data from the node borders given some cooperation from the producer's whitespace choices. It was designed to solve one problem: html was really good, but not quite right.

So we argue over how verbose node borders need be. '{ }' pairs would be advantageous when considering machine processing efficiency and network bandwidth. Yes, true, but deep hierarchies would look to us humans like bad non-refactored LISP programs. I also suspect that an XPointer such as person.birthplace.state would be harder to derive in a tree of bracket-bordered nodes unless both parties absolutely have the correct version of the hierarchy map for reference. In short, a more terse node bordering comes at the cost of less information represented within the document. The less information the document carries, the more the producer needs to know, and this is the age where the operating assumption for communication is that the consumer has a machine, a network connection, and a browser which renders marked-up text and that's all. XML is for people and so what if the machines have to read more characters?

Re:Honeymoon is Over?

[durnurd]

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

You mean, like, 8086 machine code? Or, for that matter, VAX machine code, or even some CISC machine code? I wouldn't want to write that. I'm certainly thankful we have a tool that does that for us so we can work with the ideas at a higher level.

Re:Honeymoon is Over?

[Anonymous Coward]

If you would RTFA, you would see that the screenshot from the Google page they are quoting clearly states that they "encourage you to use the AJAX Search API instead". So clearly it is about deprecating SOAP in favor of something simpler.

Re:Honeymoon is Over?

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

[chris_mahan]

> SOAP is not complicated; creating a SOAP client/server is *MUCH* simpler than creating an XML-RPC client/server if you are using the proper tools.

Using the proper tools, it seems, is the key to SOAP.

Tried it with Python lately? RPITA.

XML-RPC in python is a breeze, both server and client (client: 1 line to import the xmlrpclib library, one line to implement the server proxy, and one line for each call. like this:

import xmlrpclib
service = xmlrpclib.ServerProxy(r'http://example.com/')
result = service.getState(44)

and that's it.
if you want to be fancy,
(using '___ ' to simulate indentation )

import xmlrpclib
service = xmlrpclib.ServerProxy(r'http://example.com/')
try:
___ result = service.getState(44)
except:
___ print "didn't work" # or some variation

And that's hard how?

Anyhoo, go visit
http://docs.python.org/lib/module-xmlrpclib.html
and
http://docs.python.org/lib/module-DocXMLRPCServer. html

Enjoy!

Re:Honeymoon is Over?

[the_womble]

It depends on why how they make their money.

Google rely on ad revenues, so they need people to visit their site.

What about Amazon web services - as long as people buy, they make money. It does not matter how the access Amazon.

The BBC API for getting schedule information is not something they want to make money out of either.

Re:Honeymoon is Over?

[rbanffy]

The fact is that you _can_ write useful x86 code with nothing more than an assembler. You can write C code with a text editor. You don't need an IDE to do it. It's not even that much painful to do so.

But most of the stuff SOAP is made of would require you to edit and keep coherent a set of XML files that are remarkably human-hostile. That's why it requires a fairly sophisticated and complex tool.

Re:Honeymoon is Over?

[durnurd]

The fact is that you _can_ write useful x86 code with nothing more than an assembler.

I was referring to the assembler as a tool that writes code for us. Otherwise, we'd have to do it all by hand. *shudders*

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

Re:Honeymoon is Over?

[GreyPoopon]

Otherwise, we'd have to do it all by hand. *shudders*

And even this is not so difficult, given that each of the mnemonics correspond exactly to a hexadecimal code. All you need to hand-assemble is a table mapping the mnemonics to their hex equivalents. I used to do this frequently for embedded devices.

Re:Honeymoon is Over?

[Kazoo the Clown]

So we argue over how verbose node borders need be. '{ }' pairs would be advantageous when considering machine processing efficiency and network bandwidth. Yes, true, but deep hierarchies would look to us humans like bad non-refactored LISP programs.

Exactly, which should tell you that it's a bad non-refactored encoding.

XML is sort of like unrolling loops in code. In code however, there can be a good excuse-- performance. So--- Easier to parse? Easier to generate? Easier to read? Better for performance? Better data compression? Just what exactly, is XML's excuse?

Now I get it-- it's harder to implement. Just the thing market-protecting monopolist corporations need most to slow down the competition and delay interoperability...

Re:Honeymoon is Over?

[virtual_mps]

No you're not. The sad thing is that before the invention of XML there already was a great standard for this: ASN.1

Wow, I've never heard ASN.1 called "great" before. "Difficult to implement", "overly complex", "product of telecom committees"--those I'm familiar with. If you look at the history of ASN.1 parser security problems you'll get some idea of just how hard it is parse sanely in the real world for all corner cases.

Re:Honeymoon is Over?

[cygnus]

/me grabs cyngus and holds him/her down

WHO ARE YOU? AND WHO SENT YOU?

Re:Honeymoon is Over?

[Angostura]

Well that just about wraps it up for computers, then.

Re:Honeymoon is Over?

[Hercynium]

Hmmmm... I work in telecom and ASN.1 parsing, generation and debugging is a constant nightmare.

I have dreams where ASN.1 has been replaced by XML and the sun is shining and the birds are chirping and there are happy little munchkins singing "Ding dong the witch is dead!" ...But then I wake up to the sound of my pager because a firmware update changed the VarBind order of a notification type and the freakin' SMI compiler choked on the syntax...

Re:Honeymoon is Over?

[ibjhb]

eBay does have an API

Re:Honeymoon is Over?

[larry bagina]

Otherwise, we'd have to do it all by hand. *shudders*

And even this is not so difficult, given that each of the mnemonics correspond exactly to a hexadecimal code. All you need to hand-assemble is a table mapping the mnemonics to their hex equivalents.

That doesn't work so well with x86, where you have variable length instructions (some 10+ bytes long) and prefix bytes to specify if the operand is 8 bit, 16 bit, or 32 bit, or lock the bus, etc.

Or even ARM, where instructions are all 32 bits, but you may need to encode 3 registers, immediate values, condition codes, and bit shifting.

Re:Honeymoon is Over?

[Agelmar]

XML is not for humans. "Assess the validity of the document"??? There's no way in hell that I could give an XML document to the boss down the hall and expect any sort of magic understanding due to there being a few tags. Frankly, a printout of SELECT * is likely just as readable for most cases where a human has any hope. (And I'm guessing you didn't mean validity in the sense of 'Is this XML document valid / standards compliant', because humans definitely suck at that.)

XML's primary purpose is "to facilitate the sharing of data across different information systems, particularly systems connected via the Internet". It was designed to also be human readable, but that was not its primary focus, and I think that's what really screwed it over.

"So what if the machines have to read more characters?" Are you mad man? Let's take our favorite example, the stock quote. I want to send a symbol (typically 4 characters, so let's just say an average of 5 bytes assuming it's null-terminated string) and get back its price (a double, typically 8 bytes, although for stocks since you don't want wierd rounding errors it's probably better to represent it as an integral number of cents, so just use an int64 - 8 bytes). That's an average of 13 bytes. Rather than just opening a socket connection and sending 5 bytes, receiving 8, I send some huge SOAP message that is a request, and get a huge SOAP message back. This is on the order of hundreds of bytes... but let's imagine that somehow we get rid of all of the message, and somehow just magically open a socket and send some XML.

What I'm now sending, even in the best case, is:
<stock>.DJIA</stock>. That's around 20 characters, instead of four.
My response:
<stock>
<symbol>DJIA</symbol>
<value>12463.87</value>
</stock>

Heck, let's ignore all the tags, and just look at "12463.87". I now have to parse out the number, I have to call something like atof (which, by the way, is much worse than something like htonl), and that's totally ignoring the bloat in size for larger numbers, or numbers with a large number of digits (be they either large, or with a large number of digits after the decimal place).

It's just bloated, and it sucks up CPU resources and bandwidth. And please don't tell me that either are cheap - because if you really believe that, then you can pay my monthly bill. I'd gladly sign it over to you.

Re:Honeymoon is Over?

[rbanffy]

OK. It was a poor example. The x86 is a horrible, terrible, poorly tought-out, really lousy, crufty architecture. It's crazy to imagine someone would subject him/herself to do hand-assembly for it.

I used to do hand-assembly on the 6502 and could look at hex dumps and disassemble a lot of them in my head, but the 6502 was a small, simple and elegant design. IIRC, the 16016 and 32032 were even easier, but I never tried that for real.

It's really sad we live in the Age of the x86...

Re:Honeymoon is Over?

[D Sarathy]

Without SOAP Google may stink. Hope Google does something to wash this off.

Re:Honeymoon is Over?

[newt0311]

oftopic but whatev. I have a simple question with regards to XML vs. SGML. I have looked at the parsers for both and SGML parsers seem to be faster. As I inderstand it, SGML is a pure superset of XML. If so, why are SGMLparsers faster? and If they are (who knows, I may be wrong on this account), why is everybody still interested in using XML when they could just use SGML and all its features instead?

Re:Honeymoon is Over?

[chickenandporn]

I think you're describing something between CORBA and CMIP.

SOAP was simpler to setup (no broker and associated config), easier to grasp publication of servants, and the data packet can be debugged on-the-wire, so you can code-test-debug until it goes. CORBA is a binary format that is more optimal on the wire, but harder to debug. There's Other Issues, but These issues are Mine.

Even thought I can sit in my figurative armchair and say "seen it before", in truth these concepts co back and forth (or iterative cycles, take yer pick) and feed off each other to evolve. Maybe Son-of-CORBA is on our horizon: a better, leaner, easier RPC.

Critical Mass: The perl/python/php/ruby/etc/etc extensions didn't come for CORBA quickly enough :)

For me, there's the SOAP-to-CORBA bridge. Maybe someday I'll have time to hack on that a bit :)

CMIP-to-SOAP-to-CORBA bridge? That would be fun. More hack, less Slashdot. Don't need to find a hidden cache of German tanks to realize even that might be a bridge too far...

Re:Honeymoon is Over?

[krishy]

Ahem. sorry for the misformatting... The irony! misformatting by 'TeXMaster' :)

Re:Honeymoon is Over?

[tzanger]

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

I used to think the exact same way until I ran across some of the problems of XML-RPC. Namely the lack of NULL, and the lack of some data typing. Sure, you can throw those kinds of checks in the application and work around it, but complex as it is, SOAP has its place. There ought to be a happy medium as a standard, but there just isn't. :-(

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 - it's a good book too, I'd highly recommend it if you're doing web programming.

Re:bastards

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

Re:bastards

[xoyoboxoyobo]

Bastards, I just bought one of those books! And I got no key!

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

Re:WTF is SOAP?

[MeanMF]

Spoken like a true Slashdotter... :)

Re:WTF is SOAP?

[wyoung76]

It's something you use to wash yourself with...

oops... sorry.. wrong forum...

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 might be what you're looking for.

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?

Re:What about XMLRPC?

[Bob of Dole]

You write your own damn search engine :)

Re:What about XMLRPC?

[BrynM]

There's also the Data API.

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

[Anonymous Coward]

Agreed 100%. The folks who made the SOAP spec need their heads examined.

Re:What about XMLRPC?

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

Re:What about XMLRPC?

[mporcheron]

i cracked the ajax api to get the exact request uri for that reason ( http://mpwebwizard.com/free_stuff/google_web_api has the url to query google web search)

Re:What about XMLRPC?

[Anonymous Coward]

They are not just replacing an API. If you read the License Agreement you'll find that you are not allowed to change the appearance or remove ads. I'd say that this prevents you from doing anything fancy (mashup, data crunching) with those results. Do I understand this correctly? I can't write a Flash Application that represents search results as flying bananas, right? Using the search results to determine the size of a banana is also illegal, right? Please correct me, if I'm wrong.

Re:What about XMLRPC?

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

Re:What about XMLRPC?

[mporcheron]

because it is (and was) more fun to spend time working through the code then it is to use packet sniffer

Re:What about XMLRPC?

[nstlgc]

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

Re:What about XMLRPC?

[Anonymous Coward]

What are you talking about? The SOAP spec is 24 pages. It's not that complicated.
Its the WSDL and XML Schema things they put on top that are bloated, overdesigned crap. Not the SOAP spec itself.

Re:What about XMLRPC?

[SpinyNorman]

The AJAX API isn't a replacement for the deprecated SOAP one - it's an entirely different (and less useful) type of service.

The SOAP API let you obtain search results/etc and use them as you saw fit in your program.

The AJAX API let's you embed Google-generated search boxes and results (& advertisements) in your web page.

Re:What about XMLRPC?

[MPHellwig]

And I think this is where sub-professions differ, I enjoy coding, being a network administrator, but if given the choice to find the answer by getting through the code or grepping my tcpdump.
Heck I chose tcpdump anyday, so I would make the same 'fault'* of doing something inefficient because it's mor fun :-) How luckily people differ, otherwise it would be a very boring world for the rest.

*CEO(tm)

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.

looks like its the beginning of the end...

[Anonymous Coward]

...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).
Besides we have tons of sights with free web services floating around...

Re:looks like its the beginning of the end...

[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:WTF is SOAP?

[jours]

> WTF is SOAP?

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

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:Soap, what was that?

[aesiamun]

sudo masochism
Password:
sudo: masocsudo: command not found :(

Google says;

[ameline]

No SOAP, Radio!

Good news for a change!

[Anonymous Coward]

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

With one stroke, my technical reading backlog and books-to-buy list just got a lot smaller.

Did you mean...?

[DECS]

Google: _SOAP___

Did you mean: _soup?_

Re:WTF is SOAP?

[drpimp]

SOAP ???

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!

[Anonymous Coward]

You never read about their IPO?

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!

[Anonymous Coward]

Wow, if shutting down a SOAP API fits your definition of evil, you must live on one righteously straight and narrow path. Or you're a tool.

I know where my money went.

Re:Don't be evil!

[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. Dell was once viewed with incredible admiration for its ability to execute. Et cetera. Sooner or later, all these big companies will disappoint you, even if (or maybe *especially* if) the founders stick around.

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

[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 appropriate type. All the hard stuff gets handled by the library.

Uncleanliness is next to Satanliness

[Anonymous Coward]

Without soap Google will become evil.

Re:Uncleanliness is next to Satanliness

[Anonymous Coward]

So Google will sit next to Bill Gates?

Re:Uncleanliness is next to Satanliness

[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:(SOAP is a WS) != (WS is SOAP)

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

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

Re:WTF is SOAP?

[Anonymous Coward]

oops... sorry.. wrong forum...

Indeed. On slashdot, soap is a masturbatory aid.

Death of SOAP?

[Anonymous Coward]

Soap reminds me of corba. Complicated, opaque, and confusing. Not that I was unable to use soap with "great success" or anything, but god damn. Give me version 1.0 EJBs any day. Actually, don't. XML-RPC seems okay if you are into simplicity. Just remember to base64 encode your binary data or unicode text.

Re:WTF is SOAP?

[welshsocialist]

According to WP, it stands for Simple Object Access Protocol. I know no more than that.

Bah

[Anonymous Coward]

I got yer webservice API right here

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:loss, opportunity, lesson or deja-vu?

[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:loss, opportunity, lesson or deja-vu?

[deanlandolt]

Google is a company...Their responsibility is more towards their shareholders, not so much towards their users.

I'm pretty fed up with this prevailing Slashdot view of all public companies, just as I'm increasingly finished dealing with/investing in any company, public or private, that would prefer bow to their investors rather than service their customers, past present and future. Techdirt had a pretty solid analysis yesterday about craigslist and the whole myth of maximizing [short term] profit. What I'd like to know is when these Wall Street analysts lost sight of that ol' outdated capitalist notion that what's good for your customers is ultimately going to be goddamn good for you?!

But Google's actually a little different -- they took an end-around from some of the Wall Street pressure by withholding voting rights from their share sales. Investors know this (or should) going in, and the crippled voting writes are factored into the shareprice accordingly. This doesn't mean Google won't be evil, just that withdrawing their SOAP API probably had dickall to do with maximizing revenues or protecting brand value. Have you tried to code to a SOAP service? Without a tool it's a practical impossiblitiy. I'll wager there's a ReSTful interface already in the works. I'm surprised they went SOAP in the first place -- it really isn't Google style.

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

Open Source Honeymoon is Over?

[Anonymous Coward]

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

Which is why Open Source will never fly.

Re:Open Source Honeymoon is Over?

[newt0311]

companies only have a problem sharing the source of tech that they are directly making cash off of. A good example of companies open sourcing would be JAVA where it makes perfect sense. Sun make no (direct) money when you DL a copy of their JVM off. By open sourcing the JVM, sun gets a bunch of free testers and devs to help them out. It is also possible to build a business model around open source. Just look at Red Hat. In some cases, open sourcing a core software product may also be benificial such as in security software where this could be used a leverage to find bugs and convince customers of the security of the products. Open source is unlikely to fit in every buisiness model but it certainly has many valid applications in the business market.

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:That's unfortunate

[simscitizen]

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

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

And the replacement

[brajesh]

The recommended replacement AJAX api not only has limited applications, but also it promises 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:WTF is SOAP?

[Anonymous Coward]

wikipedia to the rescue

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.
  

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

Oh please..

[Anonymous Coward]

No, it's not the end of SOAP, it's the end of Google providing SOAP services. Free SOAP services aren't out numbered by vendor provided SOAP services. You know, like between two companies.

SOAP Nazis

[Anonymous Coward]

No SOAP for you!

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:Oh! Come On.

[kripkenstein]

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

"Soap? ...it's self-cleaning!" - Chandler

Re:Oh! Come On.

[badzilla]

Well I saw on TV that "nothing cleans cleaner than Snazzle", which everyone knows is really just another way of saying Snazzle cleans cleaner than anything. Including SOAP. That any help?

Re:Oh! Come On.

[larry bagina]

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?

I hear that AJAX is stronger than dirt.

Fight Club

[Lethyos]

Tyler Durden says: use SOAP?

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:who cares

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

Ermm

[Anonymous Coward]

Not deprecated as normally used in IT, since they've completely axed it instead of phasing it out.

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.

Re:Google != web

[Anonymous Coward]

Google has dropped HTML a long time a go, and switched to tagsoup.

Re:Google != web

[laffer1]

For some people, it would be the end of AJAX. I don't think I'm that lucky though. To me, AJAX is just DHTML again. Sure there are some additional uses for it, but most people are trying to use it like DHTML.

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

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

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:No SOAP, Radio

[Daoenti]

deprecation means an API change, not a feature shutdown

"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya

2 : to express disapproval of
3 a : PLAY DOWN : make little of b : BELITTLE, DISPARAGE

(Note, definition 1 obviously doesn't apply to this situation). Deprecation it's self doesn't have anything to do with an API change. When a feature/API is deprecated all it means is that they don't want you using it anymore. Yes, this typically occurs when an API changes and they've replaced it with something better, but there's nothing to say that's the only time that things get deprecated. I think Google used the word in perfect context here if they are expressing disapproval of using their entire SOAP API.

Re:No SOAP, Radio

[Doc Ruby]

Good point. Now that I know that their AJAX API is just a presentation layer, not a data access, API, it's clear that Google isn't just "deprecating" an API. It's depreciating the value of that API to outsiders, to capture more of the value for Google. I expect subsequent revisions to include authentication for charging for access to Google.

Re:No SOAP, Radio

[Doc Ruby]

No, I know what it means. Just because "deprecation" in favor of a new API is inconceivable to you, doesn't mean that you're looking in the right dictionary. Wherever you got those definitions - and you didn't even cite the first sense, which should have told you that you were looking in the wrong dictionary, for the wrong dialect.

To programmers, "deprecation" means:

Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favor of a specified replacement.

I don't care what the English Lit grads mean when they use that obscure English dialect. When you're talking to programmers, we expect deprecation to come with a new replacement.

Re:No SOAP, Radio

[diltonm]

"Although the term "Ajax" was coined in 2005, most histories of the technologies that enable Ajax start a decade earlier with Microsoft's initiatives in developing Remote Scripting." -http://en.wikipedia.org/wiki/Ajax_%28programming% 29

Re:No SOAP, Radio

[Doc Ruby]

Also in 1995, my independent team added an XCMD to Macromedia's Director that let Director "movies" fetch URLs, including data from remote databases. We used an SGML dialect to mark up the datafeeds, like we'd done for realtime financial info. The GUIs were updated asynchronously.

AJAX. Even if spelled ADAS.

Business matters

[Cybert4]

Sick of the gosh darn /. communists. Some people WORK for a living.

The small guys are paying for this..

[indraneil]

A friend of mine from a 50 people shop called me to check what I thought of Amazon web services. I frankly had no opnion since I am not much into web services, but I guess this is because, they were using Google SOAP APIs for themselves.
I am sure they would much rather look at another SOAP oriented service provider than change to AJAX, and I can understand their concern. They never did expect to be desupported (even on a beta product) since it was google they were discussing!
This does make me worry about the other google services I use (Gtalk, GMail etc.)

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.

Re:Drop-In Replacement Already Available

[mandelbr0t]

Don't do this, please. It's one thing to screen-scrape when there's no alternative available, but it's not like Google is removing SOAP support without a replacement. Then again, why bother worrying about manners when we're still worrying about the law?...

mandelbr0t

Re:Drop-In Replacement Already Available

[feste12]

"when there's no alternative available"

You're correct in that the SOAP API is still available for the time being. However, they've stopped giving out new API keys. Unless you have an existing key, you won't be able to use the service.

Re:Drop-In Replacement Already Available

[phil.bachman]

Scraping is against the terms of service. However, if you wanted to write up one of those on your own, check the syntax of Google's result pages. The syntax for both submitting requests and the returned results are incredibly regular. You can write up your own requester/parser in a couple of hours at most if you're at all familiar with regexes and your language of choice's HTTP libraries. Further, any of the APIs that they offer are likely to be over (depending on your needs) restrictive, so if you want to do any real heavy lifting you'll have to lie/cheat/steal. Writing your own API can be quite useful for doing specialized bulk batch searching and customizing the form of returned results to your hearts content.

Rest in Peace

[butlerdi]

Over at Amazon they have continiously been reporting dimininshing numbers of users for their SOAP based services. I think the last count was around 90% Rest Based Access to 10% Soap.

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

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). 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 cost, and should increase their band width by reducing their output to smaller chucks with the same information. The following files would be cashed on the client side, HTML, CSS, JavaScript, XSLT, and XML; So a simple change to one file, and the Client Side will download only the changed file. The Server Side has only a Simple Web Service of one input entry point, and one exit point. The Client sees faster turn-around, the Server sees a bigger band-width.

"Slowly, one by one, the Penguins steal my sanity." - Unknown

Re:WTF is SOAP?

[Anonymous Coward]

Have we already forgotten about Snakes on a Plane??

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.

"Does this..?"

[TheRealSync]

Does this mark the beginning of the end for SOAP or for ubiquitous middleware in general?

Does this mean google has turned evil? Is Bob your uncle? Will we ever see the day when a slashdot submission doesn't include an "interesting" question by the submitter?

These questions - and many others - will be answered in the next episode of Soap.

Straw Man

[Anonymous Coward]

Your argument is wrong.

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. The fact that google is looking after the interests of the shareholders, and not after the interests of, um, ... Greg Stein, does not mean that all ethics can be bypassed.

First you do the right thing and then you look after the interests of the shareholders. Otherwise, capitalism will lead to serious crimes commited by corporations.

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!

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.

A JSON alternative...

[Anonymous Coward]

<?php

function url_fetch($url) {
    $curl = curl_init();
    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
    $res = curl_exec($curl);
    curl_close($curl);
    return $res;
}

$query = count($argv) > 1 ? $argv[1] : 'google';
$offset = 1;
$limit = 10;

$url = 'http://www.searchmash.com/results/' . $query . '?i=' . $offset . '&n=' . $limit;
$results = json_decode(url_fetch($url), true);

var_dump($results);

?>

Re:A JSON alternative...

[funfail]

This is very interesting. Is it a documented feature of SearchMash?

Re:A JSON alternative...

[larry bagina]

$query = count($argv) > 1 ? $argv[1] : 'google';

bad programmer! no cookie!

$query = count($argv) > 1 ? raw_urlencode($argv[1]) : 'google';

(That's a nifty trick though!)

Unfair mods

[Anonymous Coward]

Parent is not a troll, the link takes you to an Amazon page with a book the grandparent did author.

What Business Reasons?

[RAMMS EIN]

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

Re:What Business Reasons?

[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 service that had no tie to generating revenue would be at risk.

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.

Re:WTF is SOAP?

[Anonymous Coward]

OK if we're doing stereotypes, you're fat, stupid, ignorant, arrogant, nerdy and the whole world dislikes you. Now get over it :)

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

[one4nine4two]

But if we didn't build roads and cities, then Google Maps could not exist. So therefore Google owes us for that? Pretty slippery slope there.

It's a mutually beneficial relationship (humanity and Google) and quibbling over who owes who what and how much is pointless. The same argument could be targeted at any entity.

Base Data API

[br0k_sams0n]

Eh, I'm a bit confused by the myriad of APIs available for google, but doesn't he Base data API provide the same features, just over their REST/ATOM feeds? With my key these still work quite nicely, don't use SOAP and aren't depricated: http://code.google.com/apis/base/samples/python/py thon-sample.html

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

[theshowmecanuck]

:-p

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:Power of SOAP

[bjk002]

"The real power of SOAP"...

is at the end of a long day to get the stick of everyone elses muck off of you.

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.

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:Check out Google's wrongdoing!

[Anonymous Coward]

Google is an outsourcer of US jobs to other countries, at a time when many US tech workers are unemployed. Full list.

How dare they take work away from wholesome American assholes! They are evil I tells ya!

Wild idea:

[hummassa]

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

Re:So Google is starting to act like a real busine

[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 pretty badly before you get banned. I was running at ~3 query/sec for a few hours before I got banned. Yeah you feel really stupid when you can't use Google anymore... At ~1/2 query/sec I was able to fetch about 30k pages without problems. There was interesting infos that you could only get with the API but I can live without it. If they had increased the query limit, there would be serious users out there, with the current restrictions, I don't think there are any.

What?

[mutube]

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

Red herring

[Anonymous Coward]

Where's the straw man?

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.

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.

Re:Tooling is the wrong solution to SOAP

[Mean Variance]

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:

...

And then fold digital signatures into the SOAP message. Oy vey, what a mess. It took 4 weeks to reimplement that "standard" when IBM's implementation for JDKs 1.4 and below was not supported in JDK 1.5.

It turned into one big exercise of engineers throwing shit against the wall until something stuck.

Semantic web won't fly ??

[knn693]

Semantic web is going to be there as its going to be more of meanings and rather than structured data. Nyways lets see

Oh well

[Anonymous Coward]

Yahoo Search API, anyone?

http://developer.yahoo.com/search/

SOAP SUX!

[bjk002]

Glad its leaving. Lets have a parade.

Re:WTF is SOAP?

[ayjay29]

No it's not!

But WCF (Windows Communcation Foundation) is SOAP based in some protocols.

I actually asked a couple of MS developers (this is a true story):

Me: You guys should do a "Windows Transaction Framework" and call it WTF.

Microsoft Devs: Gee, maybe we will one day.

I hope so, I really hope they do...

Sounds like

[Gr8Apes]

sounds like a subset of XML combined with XSLT. XSLT will allow you to create just about anything out of your XML. That's why people like XML these days. Now, I'll agree with you that some XML based implementations are not optimum, but you can create crap out of anything.

Re:WTF is SOAP?

[p_skelin]

Simple Object Access Protocol.
What the fuck is WTF?

Wow.. I was just saying...

[fury88]

.. this yesterday. I am trying to figure out this nightmare of a web service I've been handed with no documentation. I was just talking to a friend of my via IM and telling him no wonder web services haven't really taken off. I mean sure they are around but they aren't widespread. It reminds me of EJB. The concept is great but good luck implementing them. Too complex IMO.

I don't understand this...

[Anonymous Coward]

I find SOAP incredibly easy to develop for.

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?

Re:I don't understand this...

[LizardKing]

Nice try, but you have to write the WSDL before calling your WSDL compiler, that's time consuming, as the WSDL authoring tools I'm aware of are totally inadequate.

Supply chain management

[Anonymous Coward]

'nuff said

The S Stands for Simple

[sottovoce]

I'm not overly depressed at the decision to get rid of the SOAP API. See: The S Stands for Simple.

Maybe Google will follow in Yahoo!'s footsteps and implement a REST API now. Maybe.

There's an alternative.

[Anonymous Coward]

It's called "EvilAPI" and it's available at http://evilapi.com/ -- it re-implements the old SOAP API with page scraping.

It's not the end of SOAP because of Microsoft

[trimbo]

Does this mark the beginning of the end for SOAP or for ubiquitous middleware in general?"

Microsoft's tools make it so easy to use SOAP that it would be foolish to say it's "the end of SOAP." While Microsoft only has 31% of web servers out there in the wild (according to Netcraft), I'm sure internal corporate web efforts are 50%-50% Microsoft or better. ASP.NET 2.0 and Visual Studio 2005 are an amazing combination for writing web services using SOAP (as other posters have noted)

So, no, SOAP is not going away. Besides, who was building businesses around Google's SOAP API? Certainly not Google.

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

[Luscious868]

Web sites existed and prospered before Google. You're making a straw man argument. Whether or not Google has helped certain web sites succeed has no bearing on the fact that it is hypocritical for a company that makes it's money on the backs of content produced by others to be making moves that prevent others from doing essentially the same thing.

Re:So Google is starting to act like a real busine

[Anonymous Coward]

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

Bring it motherfucker!

Re:WTF is SOAP?

[Anonymous Coward]

No. Are you from France?

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

[Anonymous Coward]

Yes, without google I would have never found http://stores-cars-computers-business-purchase-sel l.asdf.com/ ...where I can buy Viagra.

Nomination for "Dumbest comment modded Insightful"

[WebCowboy]

the semantic web and web services will never fly. Companies don't want to make their data and services available to each other.

I shake my head that this was modded "insightful". Sounds more like a troll to me but whatever. Either timeOday is a master at trolling or he has his head very far up his arse. I hoe it is the former but fear it may be the latter.

In my career I've seen companies spend a GREAT DEAL of time and money trying to "make their data and services available to one another". They don't do this because it is a fad--they do it because they HAVE to to stay competitive and there is a very convincing cost-benefit-analysis argument to do so. There is a VERY large industry in systems integration and EDI (electronic data interchange). Companies have spent millions on systems based upon SAP and IBM WebSphere and the like to do EXACTLY what you day companies don't want to do! ERP systems are being upgraded to accept orders from customers, to send orders to suppliers, utility billing and monitoring, financial reporting to meet securities regulations, etc...ALL USING WEB SERVICES and related technologies. In fact, manufacturers who deal with large retailers HAVE to do this to survive--you HAVE to have a very close electronic link with Walmart's suppliy-chain management system to even have the privlige of getting shelf space in their stores!

Companies have been trying to share data and otherwise interact electronically for decades, and success has always been limited to some degree. This mostly has to do with the EDI industry being infested with proprietary, single-vendor formats and protocols and the expense associated with implementing and integrating them. Web services demolish nearly all those barriers. It is not only not a fad, the hype is actually giving way to an uptick in actual, real-life implementation of the technology!

I cannot say whether the demise of Google's SOAP API is being done in the name of simplicity but I CAN tell you it has nothing at all to do with the failure of the semantic web, OR web services because they are nto failing at all. However, Google DOES subscribe to the KISS philosophy and has recently redoubled its efforts to keep to that philosophy while it grows its product and service line along with its corporate size. Therefore simplicity probably is the most likely reason. They will have an AJAX API with which to offer their searching service to others without visiting their site, and SOAP really IS overly complex to provide such a function.

All in all, I think it is a sign that the web services space is maturing and becoming more sophisticated. There are well known and better-suited alternatives to SOAP for many applications now so there is no need to support it--not like in earlier times before the rise of AJAX-style apps when it seemed there was this mentality that Web Services meant SOAP over HTTP and that was it.

SOAP on ROAP

[Anonymous Coward]

...I'm waiting for SOAP on ROAP to come out.

In the meantime, I'll use a sensible framework, such as ZeroC's Ice: http://www.zeroc.com/

(CORBA got more right than it got wrong.)

AJAX API not the same functionality as the SOAP

[Anonymous Coward]

The SOAP API is a real RPC API that can be called from Python, C++, or Java programs. The AJAX API is a bundle of obfuscated Javascript that can effectively only be used with Javascript interpreters running inside Web browsers. This is a big reduction in functionality.

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

[Raenex]

It's not hypocritical. Google spends millions to maintain it's infrastructure. The average site is not spending millions. There are also plenty of content providers that want their site made as visible as possible, so they can make money somehow or just to get the information out.

And finally, just because somebody makes their content available for free does not mean somebody who adds value to it has to do the same. That's the difference between the BSD vs GPL philosophy.

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

[Anonymous Coward]

Jesus Christ! You're new to the internet, I take it... I was searching the web with Yahoo before Google even existed. Other search engines exist, and Google wasn't even the first.

Google could shut down their search engine tomorrow and most people would hardly notice. I would just click on the drop-down list by the firefox search box, pick another engine, then continue as normal.

The world does not revolve around Google

[Kelar]

Just because Google decided to cut a service doesn't mean a protocol is doomed. Get over it people, Google isn't everything. Google could go away completely and it wouldn't change the world much.

Re:Nomination for "Dumbest comment modded Insightf

[timeOday]

In my career I've seen companies spend a GREAT DEAL of time and money trying to "make their data and services available to one another". They don't do this because it is a fad--they do it because they HAVE to to stay competitive and there is a very convincing cost-benefit-analysis argument to do so. There is a VERY large industry in systems integration and EDI (electronic data interchange). Companies have spent millions on systems based upon SAP and IBM WebSphere and the like to do EXACTLY what you day companies don't want to do!

You're missing the point. Of course companies exchange data electronically, and pay good money to set up specific interchanges of information. But the vision of the semantic web and web services is quite different: that information and services will be widely available, in widely adopted formats, so that they can be harnessed together in unforeseen ways to create new applications almost in near-real time. The fact that companies still pay millions to SAP and IBM for system integration on a case-by-case basis is a strong counter argument to your assertion that this vision is already realized. If it were, I could sit at home and have my personal software agent fulfill my shopping list by querying the inventories and prices of local retailers and Internet merchants. For budget reporting I could accrue a detailed itemized list of every single item I buy at the grocery store, Target, or through online payment, grouped into categories like "food" and sub-categories like "junkfood." All this information is already recorded, but only in disparate systems and formats. Wal-Mart (for instance) tracks this sort of information closely, yet you'll be kicked out of their store if you so much as go into a store and write down the prices of goods on the shelves. The airline industry is constantly bucking legislation requiring them to state upfront the simple total price of a ticket. Same for cell phone companies. The fact is, there is strong resistance to eliminating many sources of market friction.

Point wasn't missed, you still don't get it.

[WebCowboy]

that information and services will be widely available, in widely adopted formats, so that they can be harnessed together in unforeseen ways to create new applications almost in near-real time.

Your description EXACTLY DESCRIBES a scenario in which I have direct knowledge. Where I am, industrial consumers of electricity can get market prices of electricity, both current and historical. This information is "widely available" and provided in "widely adopted" XML format. This data is "harnessed together" by power consumers in ways "unforseen" by electrical utilities to create "new applications" to monitor operational costs "in near real time".

The fact that companies still pay millions to SAP and IBM for system integration on a case-by-case basis is a strong counter argument to your assertion that this vision is already realized.

It does nothing of the sort. It actually is the exact opposite--it strongly SUPPORTS my argument. You don't even have the right idea about my argument--it isn't that the "vision has been realised"--it is that the world is catching onto the vision. Of COURSE it hasn't been realised yet--such a task is gargantuan! The reason companies have to pay for integration on a case-by-case basis is NOT because the end result is different for each company--it is because the STARTING POINT is different. And arcane. And very proprietary. There is also great inertia to overcome and the fact that there is movement at all to change the way of collaborating is a feat in itself.

All this information is already recorded, but only in disparate systems and formats. Wal-Mart (for instance) tracks this sort of information closely, yet you'll be kicked out of their store if you so much as go into a store and write down the prices of goods on the shelves.

You seem to be focusing solely on the business-to-end-consumer part of the supply chain as if the rest of the stuff didn't even exist. You completely ignore the relationship between wal-mart and its suppliers, those suppliers and their suppliers of raw materials, the transportation/distribution/logistic companies and all of the above, etc. The B2C end part of the chain is probably the least developed! You talk about having this "personal agent" doing comparison shopping for you, well Wal-mart themselves ALREADY DOES THAT--they have their own "business intelligence" software that takes data from ALL their suppliers, in a format mandated by wal-mart to their suppliers, and takes inventory data from ALL their stores and churns through it and finds out the lowest cost suppliers for each category, which stores move which merchandise the best, etc, etc. Wal-mart takes that data and uses it to it maximum potential--ruthlessly. If a supplier is not moving goods fast enough or comes out the most expensive or with the lowest profit margin, that supplier is hauled to the carpet and told to get in line or your contract will not be renewed (or it could even be terminated).

You mention "Wal-mart tracks this information closely" and then just leave it at that, like that has nothing to do with the argument. The way wal-mart does this is EXACTLY the philosophy that web service technology follows (whether or not wal-mart implements exactly this technology): Data is widely available (the network of wal-mart stores is MASSIVE and HQ can see EVERYTHING from EVERYWHERE) and is in a standard format (mandated by Wal-mart, but in our case mandated by open standards) and used in unforseen ways (walmart-continually improves its business intelligence software, and suppliers never have any idea how the data they provide is used by wal-mart). Everyone is starting to realise the potential of such a philosophy and the importance of it. We are merely at the forefront and in many years that is where things are heading.

The airline industry is constantly bucking legislation requiring them to state upfront the simple total price of a ticket. Same for cell phone companies. The fact is, there is strong resistance to elim

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

[theshowmecanuck]

Read the post (I know some poor souls, just like you, don't have good comprehension so I'll repeat this part:

...if it weren't for Google and other search engines...

Now I'll explain it: other search engines mean things like Yahoo and AltaVista, etc. If you couldn't figure that out it's a good thing you can use search engines to point your life in some sort of a direction.

Finally, we were using the 'internet' where I worked before it was commercialized in '91. I used to work in chemical process R&D and we used it during our research projects.

It's about the time to let SOAP...

[silverdr]

REST in peace!

Re:Point wasn't missed, you still don't get it.

[timeOday]

You talk about having this "personal agent" doing comparison shopping for you, well Wal-mart themselves ALREADY DOES THAT--they have their own "business intelligence" software that takes data from ALL their suppliers, in a format mandated by wal-mart to their suppliers, and takes inventory data from ALL their stores and churns through it and finds out the lowest cost suppliers for each category, which stores move which merchandise the best, etc, etc. Wal-mart takes that data and uses it to it maximum potential--ruthlessly.

Does that sound like convergence, or more like an industry dominated by a single giant? Can competing retailers (including - or especially - small ones) tap into the same supplier information systems and make use of it to their best advantage? That is where we need to be.

I will tell you one reason to focus on B2C, because that is the true test of whether stovepiping has been cured. Consumers are the last to receive access, so if they can, everybody can. The greatest breakthrough of the Internet is not that the same establishments can communicate more efficiently, but that a much greater pool of suppliers now has access to markets. E.g. bloggers competing with newspapers, and companies with tiny marketing budgets making sales across the nation.

I realize some things are slowly opening up. I only hope you are right, and all the information fiefdoms are eventualy overthrown. The economy would be so much more efficient. But to me the progress seems frustratingly slow.

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.

Re:who cares

[Anonymous Coward]

Robert Malda.

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

[WilliamSChips]

Sorry, nope. No engine provides decent quality except Google. You do realize that Yahoo pretty much uses Google search now, right?

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

[Anonymous Coward]

I'm not sure which I'm more sad about: that I read this far down the pile of comments, that your score is a "2" or just how ignorant you are. Probably a toss-up. Yahoo in no way uses Google search in their search results. They did. About 2+ years ago. Welcome to the future GOOG fanboy, time to wake up and smell the evil.

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

[Mr2001]

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). Isn't that how the search API already worked? They were handing out tokens and limiting each one to a certain number of queries per day, although I don't think they were investigating the applications for which the tokens were used.

Neither allow programmatic Google queries

[PSdiE]

Um .. the discussion about the relative merits of web service technologies are all very interesting and all, but they seem to miss the point.

For "business reasons rather than technical", Google appears to have deprecated programmatic search queries full stop - neither the AJAX API (i.e., a search box widget) nor the GData API (RSS feed related, not search) provide the same functionality as the abandoned SOAP web service API.

It would appear there is no longer a supported method of querying Google programmatically and displaying the results in a custom manner (such as unbranded website searches and -blerrrg name- "mashups").

This is a crying shame and by Google's own confession, motivated by AdSense/Google Mini sales greed rather than technical issues.

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

I like your definition of "Replacement"

[Safety Cap]

~ it's not like Google is removing SOAP support without a replacement.

If by "replacement" you mean, "something that is much more limited in scope and blocked off from creative use" then you are correct.

The new API is nothing more than an AJAX call to retrieve a widget from Google, limited to 8 search results with no paging. You DO NOT

• Have access to the raw results data
• Have the ability to reformat the results (except what you might get away with by creative CSS/JS hackery)
• Have the ability to add value to the data, say by combining it with something else to make a unique item.
• etc

The reason why they did this is obvious: they want to prevent websites from getting eyeballs with their data. With the new Google© API^h^h^h Widget®, they can^h^h^h will embed advertising and force visitors to go to their own site to get the remainder of the search results. The schlubs with websites but weak HTML/CSS/JS skills will be fine, because google made it easy -- just drop a script tag in your page and you're ready to go. Everyone else is teh 5uxxor5!

Re:I like your definition of "Replacement"

[mandelbr0t]

Seems to go along with their recent design patent. I guess they can add a fourth drawing to their patent. But I'm guessing this will be a new one.

mandelbr0t