Showing posts with label API. Show all posts
Showing posts with label API. Show all posts

Wednesday, 17 September 2008

Google Should Learn About Contacts APIs

Garett Rogers noticed a new option in the chat widget from the experimental iGoogle: invite friends to Google Talk. Unlike the similar feature from Gmail, iGoogle provides a simple way to import your contacts from Yahoo Mail, Hotmail, AIM and send mass invitations. The problem is that Google asks the username and password for a third-party email account, instead of using the APIs provided by Yahoo and Microsoft.


Google explains that it doesn't keep your username and password, but it's a really bad practice to teach your users to type their credentials on third-party sites. "Big internet companies stand to lose the most from widespread abuse of the anti-pattern, because they're the ones most likely to be targeted by phishers," says Simon Willison.

It's ironic that Google has a Contacts Data API and the introductory blog post has the following message:

"Have you ever been on a web-site that asked you for your Google username and password so that it can import your Gmail contact list? Did you think twice before giving out that information, hoping the web-site would not use it to access your credit card information stored with Google Checkout? Now you don't have to! We're happy to announce the availability of our Google Contacts Data API that gives programmatic access to your contact list. (...) We hope that APIs like this one mean you will never have to give out your username and password to other sites again. Please encourage all sites you use to switch to this API for accessing your Google contact data."

Flickr heard Google's message and it uses the contacts API to import the address book from Gmail. This way, Flickr doesn't have access to your password and it can only use a small portion of the data stored in your Google Account.

Sunday, 8 June 2008

Interesting Ways to Use Google Chart API

College @ Home lists 50 ways to use Google Chart API, a simple API for dynamically generating charts. Plot functions, visualize the evolution of the number of subscribers to a FeedBurner feed, display the results of a poll, transform HTML tables into charts and much more. Of course, you can also use Google's charts just for fun.


If you only need to create a few charts, generators like Chart Maker, Google Chart Creator, Chartpart let you create charts without reading the documentation. To use Google Charts programmatically, check this list of wrappers for Java, C#, PHP, Python.

{ Thanks, Fiona. }

Tuesday, 27 May 2008

Google Hosts Popular JavaScript Libraries

If you've ever wanted to use a JavaScript library like script.aculo.us, Prototype, jQuery or Dojo, but you couldn't upload its files to a site or you found it difficult to manage all the different versions, Google hosts them for you.

"The AJAX Libraries API is a content distribution network and loading architecture for the most popular open source JavaScript libraries. By using the Google AJAX API Loader's google.load() method, your application has high speed, globally available access to a growing list of the most popular JavaScript open source libraries. (...) The AJAX Libraries API takes the pain out of developing mashups in JavaScript while using a collection of libraries. We take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes".

In addition to Google's APIs for search, maps, feeds and translations, you can now access AJAX libraries that add useful features like drag-and-drop, controls, animations or easier DOM manipulation. You can use Google as a fast proxy, but Google also caches the files related to iGoogle gadgets, the feeds that are served by Google Reader, and we should expect to see more content that can be accessed from Google faster and more reliably. In the future, Google could provide even more tools for a site: stats, monetization, search are useful, but what about using an unified Google API that lets you find facts, get spelling corrections, add ratings and forms, store data, add social features and code applications that run on Google's platform?

Tuesday, 22 April 2008

Google Search REST API

More than one year after Google discontinued the SOAP Search API, it finally got a proper replacement. The AJAX Search API can now be used from any Web application, not just in JavaScript. The other two Google AJAX APIs for feeds and translations were updated for non-AJAX use, as well.

"For Flash developers, and those developers that have a need to access the AJAX Search API from other Non-Javascript environments, the API exposes a simple RESTful interface. In all cases, the method supported is GET and the response format is a JSON encoded result set with embedded status codes."

"Using the APIs from your Flash or Server Side framework couldn't be simpler. If you know how to make an http request, and how to process a JSON response, you are in business," says Mark Lucovsky. Here's a simple example for web search:
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Earth%20Day

There are some differences between the old SOAP API and the REST one.

PROs:
- the new API doesn't require a key
- there's no limitation for the number of queries
- it's much easier to use
- you can use the REST API for web search, but also for image search, news search, video search, local search, blog search and book search.

CONs:
- you need to send "a valid and accurate http referer header"
- you can only get up to 8 results in a single call and you can't go beyond the first 32 results
- the terms of use are pretty restrictive: for example, you need to attribute the results to Google and you are not allowed to change the order of search results.

It's interesting to notice that Yahoo's search APIs are more developer-friendly and, although they require an application ID and have some usage limitations (5,000 queries per IP per day), they offer more features and they are more flexible, by also including XML output. Another important difference is that Yahoo doesn't require "a valid and accurate http referer header".

Philipp Lenssen suggests that it's much easier to just screenscrape the results, but search engines could change their code or block your requests.

Update. Check this excellent interview with Mark Lucovsky, who mentions that the API has been available for almost two years, but it wasn't officially documented: