Is Data Dead?
Some things never make it out of Beta. Recently, Google deprecated their SOAP-based Search API (Beta) in favor of an AJAX Search API. With this sudden announcement, Google is no longer issuing keys and has even pulled their SOAP API SDK out.
Want to integrate web search into your app? The SOAP APIs let you dispatch requests to the search servers and get responses (think ordered lists), that you could display however you choose to, or generally do whatever you wanted with them. Google’s new AJAX API replacement is much in the mold of AdSense and YouTube APIs: it occupies an “island” on your user interface real estate. Context and basic customization options aside, you have no control over what gets shown in that island. [Update: I stand corrected on this last statement. Mark L clarifies that the AJAX API offers other options giving you some control.]
Tea leaves
For a variety of reasons, developers have found this to be a worrisome turn of events. Apparently, in addition to the loss of flexibility, there wasn’t any advance notification on this decision, nor a REST or GData replacement API. The AJAX APIs (currently) allow 8 results only, a departure from the flexibility of the old SOAP APIs. Google’s Terms Of Service forbid you from hacking on the AJAX API and screen scraping results or manipulating the server to give you the data and not the UI with it.
From an API use perspective, this is a step forward for novice web developers and folks who could care less about aesthetics and user experience on their web sites. With that audience, it is difficult to argue against the idea of adding search to a website with just a couple lines of script and markup. By sheer numbers, I suspect that demographic makes up the 80% of Google’s audience for these APIs. Moreover, by supporting only the AJAX model instead of multiple alternates, Google seems to be marshaling the proverbial 20% of their resources to this effort. So the Pareto principle (80/20 rule) seems to be in full play here.
Web developers of the world, all is not lost! Live Search offers you a SOAP-based API. Yahoo! Search offers REST-based APIs. If you care about sanctity of APIs or just want complete control over results, you should consider moving over. Both these are excellent search services from very developer-focused companies.
Geeks need to take a chill pill
The blogosphere is rife with conspiracy theories and some folks make this out to be a technical battle between SOAP and REST or SOAP and AJAX or APIs and widgets. I do not think that is the case at all. Google’s decision seems to be based on business decisions, not technical. As a data and service provider, Google is looking for a way to monetize the service. This way, they can inject ads and cross-promotions into the results widget. If this snowballs into a trend, it portends an end to the days of building mashups by freeloading on data from the cloud. But again, Google has probably calculated that mashups account for almost nothing on their bottom line.
Tags: Search, SOAP
Want to integrate web search into your app? The SOAP APIs let you dispatch requests to the search servers and get responses (think ordered lists), that you could display however you choose to, or generally do whatever you wanted with them. Google’s new AJAX API replacement is much in the mold of AdSense and YouTube APIs: it occupies an “island” on your user interface real estate. Context and basic customization options aside, you have no control over what gets shown in that island. [Update: I stand corrected on this last statement. Mark L clarifies that the AJAX API offers other options giving you some control.]
Tea leaves
For a variety of reasons, developers have found this to be a worrisome turn of events. Apparently, in addition to the loss of flexibility, there wasn’t any advance notification on this decision, nor a REST or GData replacement API. The AJAX APIs (currently) allow 8 results only, a departure from the flexibility of the old SOAP APIs. Google’s Terms Of Service forbid you from hacking on the AJAX API and screen scraping results or manipulating the server to give you the data and not the UI with it.
From an API use perspective, this is a step forward for novice web developers and folks who could care less about aesthetics and user experience on their web sites. With that audience, it is difficult to argue against the idea of adding search to a website with just a couple lines of script and markup. By sheer numbers, I suspect that demographic makes up the 80% of Google’s audience for these APIs. Moreover, by supporting only the AJAX model instead of multiple alternates, Google seems to be marshaling the proverbial 20% of their resources to this effort. So the Pareto principle (80/20 rule) seems to be in full play here.
Web developers of the world, all is not lost! Live Search offers you a SOAP-based API. Yahoo! Search offers REST-based APIs. If you care about sanctity of APIs or just want complete control over results, you should consider moving over. Both these are excellent search services from very developer-focused companies.
Geeks need to take a chill pill
The blogosphere is rife with conspiracy theories and some folks make this out to be a technical battle between SOAP and REST or SOAP and AJAX or APIs and widgets. I do not think that is the case at all. Google’s decision seems to be based on business decisions, not technical. As a data and service provider, Google is looking for a way to monetize the service. This way, they can inject ads and cross-promotions into the results widget. If this snowballs into a trend, it portends an end to the days of building mashups by freeloading on data from the cloud. But again, Google has probably calculated that mashups account for almost nothing on their bottom line.
Tags: Search, SOAP
4 Comments:
So will Developers shift to MSN and Yahoo for their API needs, since they are more flexible than google's ajax search API ?
By
Anonymous, at January 2, 2007 at 2:06 AM
Good analysis on the paragraph ending with "Google has probably calculated that mashups account for almost nothing on their bottom line."
I recall reading the Google maps API legam agreement and seeing the clause that they reserve the right to insert ads at any time. I've wondered how they might do that... and it looks like they've made up their mind. I suspect in the near future we might see a change (or deprecation) in the Google maps API to allow Google to better inject ads.
By
Anonymous, at January 2, 2007 at 1:20 PM
Hey, I just read your post. Question for you? How much time have you spent with the AJAX Search API? From reading your post, it sounds like you have not taken the time to explore the API or understand its capabilities.
Your characterization of the API as occupying an island on your real estate is just plain wrong. While it is true that the simplest possible way to use the API is by instantiating and populating a GSearchControl object, its both false and misleading to imply that this is the only option.
Take a look at this very simple site: http://success.salesforce.com/. This is an example of AJAX Search API integration where the programmers have built a very simple decoupled search interface that is very well integrated into their site. They are processing the completion events with their own code, inserting their own equivalents of suggessted queries, etc.
Here is another nice example of AJAX Search API integration: http://www.s-bahn-berlin.de/stadtplan/berlin.fullsize.php
You can either enter a search expression in the search box, or click on the theater, movie, drink, meal icons to the left of the box. Note the yellow markers that appear and as you drag the map, a new set of markers appears. This is all very simple to do by using the GlocalSearch() object and manually calling .execute() and processing the completion event which delivers a set of javascript objects representing the results.
Here is another site to preview: http://u-tube.ws/. Note the vertical strips of videos on either side of the stage? Click a video and the stage starts to play the video. Underneath recomended views, there is a series of links which when clicked execute a search in the left hand strip of videos. In this example, the code is interacting with GvideoSearch, processing the results, using the thumbnail properties, title property, player url, etc.
In all of these samples, the application is in complete and total control over what gets shown, how it gets shown, and where it gets shown.
You are also grossly misreading portions of the terms of service. I think you have latched on to the section on modifying results. Since this API provides programmers with raw urls, title values, snippet values, etc., in addition to a fully populated .html node representation of a result, we request that applications not modify result content. For instance, if a user does a search for ipod, and one of the results has a title of "Apple Ipod" and a url of "http://www.apple.com/store?p=ipod" we do not thinks its appropriate to use a modified URL and end up creating a search result where a title of "Apple Ipod" is hyperlinked to "http://www.mp3-superstore.com?promo=zune"
This is a mis-representation of our search result content and ends up causing confusion to users. IF a site wants to append to a search result a promotion like this, e.g., undernead the result, include a hyperlink of "Related Items from mp3-superstore", thats perfectly acceptable as long as the site isn't mis-representing this addition as somehow being provided by Google.
There is absolutely no need to scrape with this API. ALL search objects (GwebSearch, GlocalSearch, GblogSearch, GnewsSearch, GvideoSearch) provide you with easy to process result data. Take a look at this: http://code.google.com/apis/ajaxsearch/documentation/reference.html#_intro_GResult
Applications can freely mix usage of the GSearchControl UI layer alongside UI-less GSearch layers. All of this is clearly documented and is being exploited by sites very successfully. Here is a great example that demonstrates this flexability: http://www.bloggingtories.ca/
Play around with the search box and notice how this site has arranged for five parallel searches arranged in two columns with a horizontal video strip below the results. Click on a video and see how he has positioned the player between the results and the search form.
By
Anonymous, at January 4, 2007 at 9:54 AM
Hey Mark, in your zeal to prove me wrong, you glossed over the fact that the AJAX APIs require that the client understand Javascript to a large degree. Certainly, that isn't your view of the world? What of the thick client systems that don't have a script engine? What of WPF-based clients where any HTM/JS content is indeed isolated in the equivalent of an iframe?
In contrast to the SOAP APIs in such situations, the AJAX APIs do seem to me as shutting off a section of the audience. Can you give me a link or two to how these problems can be resolved?
By
Ashish Shetty, at January 5, 2007 at 6:54 AM
Post a Comment | Home | Inference: my personal blog