Perhaps nothing like this should be a surprise coming from a company that built the leading webmail product online and still calls it Beta five years later.

Who's worn the virtual cap and gown already? Twenty seven projects are listed as graduates, including the YouTube APIs, Maps APIs and (thank goodness) Contacts API. We've been wondering why more developers aren't using the Contacts API but instead keep asking us for our precious Google passwords. It's been out for a whole year now. Now there can be no excuse! The Contacts API is real, it's solid and Google is committed to supporting it.

Surprises among the 18 projects still deemed too green for prime time? Gears, Finance Data APIs, Social Graph API and the Feedburner APIs.

Google APIs are an incredible resource and today's announcement should further their adoption. We'll be monitoring the Code Labs page for the experimental availability of the inevitable Google Brain Implant API, but until that day comes we feel almost unconditionally excited about the code projects the Google teams are working on.

But as the list of Google's APIs continues to grow, there are some older APIs that are, in Google's own words, no longer "receiving the necessary love."

Those APIs that will be shut down include the Blog Search API, Books Data API, Books Javascript API, Image Search API, News Search API, Patent Search API, Safe Browsing API (v1 only), Translate API, Transliterate API, Video Search API, and Virtual Keyboard API.

Google says that it closely monitors the usage of its APIs as well as the resources necessary to support them. In some of the cases, those APIs that have been targeted for deprecation or shutdown weren't being utilized or the projects they were related to have been shuttered - such is the case with the API for the ill-fated Google Wave. But in other cases, newer APIs have replaced them - that's the case with the book-related APIs that are slated for closure.

Google says that it will suggest alternatives to developers so that they can achieve similar functionality - whether it's pointing to a new version or to a related one. It also says that it has lengthy deprecation periods - as long as 3 years in some cases - in order to help minimize the impact.

Partial response and partial update are now available for the YouTube Data API, the Calendar Data API and the Picasa Web Albums Data API. The Sidewiki Data API currently only supports partial response.

You can find a more detailed description of these new features here.

The API Playground will also become Google's official way to show Javascript samples.

The Playground runs on top of Google's App Engine, which is quickly becoming Google's preferred way of developing and releasing new products.

Ben Lisbakken, a Developer Programs engineer at Google, developed the API Playground as a "20% project." Google also made the source code for the API Playground available under the Apache 2.0 license.

Great for Learning

For students (or anybody who is trying to get his/her head around the basic concepts of using Google's APIs), this could be a great way to get some coding experience with almost immediate feedback and without having to learn the complexities of an IDE.

Yahoo's new Application Gallery

I remember speaking with ex-YPN chief Toni Schneider about this last year and I was impressed by his vision for a commercial platform for APIs. I'm expecting Yahoo to really the ante with Google and Microsoft in terms of mashup ecosystems. Don't count out AOL and eBay either. [...]

[Full Story on ZDNet...]]]> http://www.readwriteweb.com/archives/yahoo_ups_the_a.php http://www.readwriteweb.com/archives/yahoo_ups_the_a.php Yahoo Wed, 08 Mar 2006 15:30:34 -0800 Richard MacManus I've noticed some excellent techie posts lately, so I feel duty-bound to point them out.

Phil Pearson, XML expert Kimbro Staken and Movable Type consultant Chad Everett have been working on a Structured Blogging plugin for Wordpress and MT. This is to enable ordinary folks (like me) to publish "new microcontent types, support microformats and other standards like Media RSS". Phil's looking for feedback, so if you're technically inclined jump over to his blog and add your 2 cents.

Also I found a great resource via the 9rules homepage, an article at Fiftyfoureleven.com about how to use the Yahoo! API. As it states in the intro:

"Looking at Yahoo!s APIs, you can see a little of that "openess" that Yahoo! CEO Terry Semel referred to at 2005's Web 2.0 conference. From images to movies to maps and search, they offer a lot of data through their APIs."

Fiftyfoureleven.com also offers an ongoing API series. Great stuff and I'll be reading this very closely and experimenting when I get some free time (in about a week!). Also check out ProgrammableWeb's How to Make Your Own Web Mashup article. The beauty of mashups is that anyone can play, thanks to great resources like these and the backend work of folks like Phil Pearson.

JSON stands for JavaScript Object Notation. According to the Wikipedia entry, JSON's simplicity has "resulted in its widespread use, especially as an alternative to XML in Ajax".

I had the pleasure of speaking to Toni recently and I know the Yahoo folks have lots of plans around APIs. As Yahooligan Matt McAlister recently wrote in reference to a Scott Gatz speech: "Kevin Burton asked about public APIs. Scott pointed him to developer.yahoo.net where the current APIs are posted and some community efforts to help facilitate more activity. He said, Yahoo! is still testing some concepts, and the company knows that this is incredibly important. And Scott said we can expect to see a lot more in that area. "

The idea is that developers can build mini-applications that can allow real-time user interaction through the instant messaging foundation of Google Talk IM. Lettvin showed off an example of a chess game that was not only discussed over IM but played through an interface with IM-like communication infrastructure running underneath it. That's pretty hot.

University of Amsterdam student, Sander Dijkhuis, already built a collaborative text editing gadget using one of the APIs and we expect to see more interesting examples emerge shortly. Just picture ease of development plus real-time communication across different installs of little applications. There are lots of things that APIs like that could make possible.

While we're sure that developers engaged in Google social networks will enjoy these APIs (though Flash is out of the picture, it's just Javascript) we would love to see them available outside their current confines.

The point of the site, John explains in the ProgrammableWeb blog, is to "create a home page for Web 2.0 developers." That's a very worthy aim and I'll be checking the site out regularly. [link via Josh Porter]

APIs are increasingly becoming an important way to distribute information and to access services, and APIs are quickly becoming a crucial part of companies' online products. In other words, it's no longer enough to simply have a website or an app; you need an API.

Mashape plans to offer several ways for developers to make money with their APIs - via a queries limit, a one-time fee, or a subscription model.

Service providers and individual developers can make an API available and third party developers can consume any component listed on Mashape - all through a single interface. "We think there's a clear need for this. We already have over 1,000 developers signed up for the alpha," said Marietti.

ReadWriteWeb readers can use the code "READWRITEWEB" to get access to the alpha version of service.

The press release is here. Details below as they emerge, see also Centernetworks, where Allen Stern is also live blogging the call. If you'd like to listen to a recording of the call, you can use your phone (!) to do so at (800) 945-2760 for the next 30 days.

A Microsoft VP whose name I missed is going over its past efforts on software interoperability, collaboration with major open source vendors and Identity. Today's announcement of principals is a big expansion on what they've done in the past. Lots of documentation will be published immediately. A document interoperability initiative will make sure that all user created documents are usable anywhere.

APIs and communications protocols will have free "trade secret licenses" made available now and in the future those licenses won't need to be used. Noncommercial API calls will be available without cost. Patent licenses for commercial implementations of APIs do still cost a fee. Commercial and noncommercial developers are of course being treated very differently. Open APIs, with a fee for commercial application, seems a fair way to move into the future, though I can't help but wonder if it will be cost prohibitive in this case for small startups.

There are far more mentions of legal pressure Microsoft is facing than there are of data portability. The company is saying that these steps are being taken on their own accord and I'm sure there's some truth to that. "In a more connected, services oriented world the biggest value add will be in what happens on the other side of the wire," says Microsoft's Brad Smith.

Viewer APIs

ThinkFree is also shortly going to open up its Viewer APIs, for Web Services companies to mashup Viewer into new web apps. APIs will also be made available to Web designers to integrate Viewer, meaning they can insert .doc, .xls, or .ppt files directly within a service - regardless of OS, installed apps, etc.

ThinkFree Docs set to launch

ThinkFree is also preparing to launch a new document exchange product called ThinkFree Docs, which the company describes as "Flickr for Office files". It will enable content creators to share, get feedback, read, and source office documents. This service will be launching in beta shortly - a demo of the site is up now, but it is undergoing a redesign as we speak.

While data portability is a hot topic of the day, there hasn't been a lot of tangible work done around the details yet. Idealware's guide could make implementation of these themes much more manageable. Readers may also be interested in this related discussion about data portability use cases over at the DataPortability.org public discussion.