What is the Google API?

As most of the applications that I have developed have consisted of interacting with Google’s web-services via their API, I thought I would describe what underlying protocol the Google API is based on. Hopefully this post will try to explain this.I’m sure that most of you have heard of the many web service API’s that Google provides developers to incorporate into their own web/desktop/mobile applications. What each of these API’s have in common is a model called the Google Data API and its underlying protocol. The Google Data Protocol.

Google Data Protocol

The general aim of the Google Data Protocol is to provide a standard to allow a way in which data is easily read and wrote on the web. The universal language on the web currently is XML. This is the same language used to base the Google Data Protocol on, it relies heavily on XML namely in syndication formats via Atom or RSS.

In Google’s words -

Why was the Google Data Protocol developed?

Google's mission is to organize the world's information and make it universally accessible and useful. Sometimes making information accessible requires making it available in contexts other than a web browser. Thus, Google provides APIs to let client software request information outside of a browser context.

Why use syndication formats such as RSS and Atom?

Syndication is an effective and popular method for providing and aggregating content. The Data APIs provide a way to expand the types of content that Google can make available through syndication; in particular, they let you use the syndication mechanism to send queries and receive query results. The Data APIs also let you send data to Google, and update data that Google already has.

So now you know what the Google Data Protocol is based on, the next step is how as developers do we use it. Well via Representational State Transfer (REST) style calls. REST- style architectures consists of clients and servers. Requests and responses are produced around the transfer of resources. In essence the Web is built on this REST-style architecture, via HTTP requests and HTTP responses. We as users/clients request the resources whether it be a html page or a web-service call from a web-server and the server responds with the appropriate response (in JSON, XML etc)to answer this request.

After understanding the concepts of the underlying network architecture and protocol which the Google Data API is based on, it is straightforward to illustrate the general architecture.

All of the Google API’s such as the Google Health API, YouTube API, Google Documents List API and so on rely on the Google Data API.

Since the Google Data API uses a REST-style architecture, HTTP request operations such as GET, POST, PUT and DELETE are fully supported by the Google Data API. Since we are dealing with making HTTP requests the Google Data API is not restricted to any programming language, which allows it to meet Google’s aim of having information which is “universally accessible and useful”. I could use JavaScript, C++, C#, VB.NET, Java, Python and so to interact with the Google API framework and it would not matter since all we are doing is creating a HTTP request and parsing the XML formatted RSS or Atom syndicated response from the server.

Example: Requesting a feed with no entries (taken from the Google Data Protocol specification)

HTTP Request:

GET /myFeed

HTTP Response:

   
     <?xml version='1.0' encoding='utf-8'?>
     <feed xmlns='http://www.w3.org/2005/Atom'
         xmlns:gd='http://schemas.google.com/g/2005'
         gd:etag='W/"C0QBRXcycSp7ImA9WxRVFUk."'>
       <title>Foo</title>
       <updated>2006-01-23T16:25:00-08:00</updated>
       <id>http://www.example.com/myFeed</id>
       <author>
         <name>Jo March</name>
       </author>
       <link href='/myFeed' rel='self'/>
     </feed>
 
 
 

As you can see the response is in XML Atom syndicated format since this is the default syndication format supported by the Google Data API.

For more information and examples please have a look at this page.

Last updated on 3 Mar 2010
Published on 3 Mar 2010