The first integration mode is the classical one, relying on APIs supplied by Google. This allows very tight integration with the existing IS, because it occurs at the level of applications code. This way, data managed by Google Apps, as well as their key features, become available to code written by developers.
Most of these APIs implement three common mechanisms:
There is a common protocol used by several of the Google Apps, such as Google Calendar or Spreadsheet, which is called Google Data Protocol. It draws on the REST architecture. Let us briefly recall here the basic REST principles.
REST is actually more an architecture style than a genuine protocol. REST attempts to capitalize on existing protocols and technologies such as HTTP and XML to provide a simple way of exchanging information, at least when compared with SOAP, for instance, which requires complex marshalling and un-marshalling operations. When using REST, the basic data manipulation operations known as CRUD operations, are simply associated to the PUT
, GET
, POST
, and DELETE
that are defined in the HTTP
protocol. Furthermore, a resource is identified by its URL. The two main advantages of REST are its simplicity and the omnipresence of the principles on which it relies.
Any programming language that allows you to create HTTP requests and parse XML code will do for using Google Apps APIs. To make the life of developers easier, Google also provides a set of client libraries in the primary languages (Java, PHP, Python, .NET, Objective-C), which will facilitate creating HTTP requests by using an appropriate set of abstractions.
We shall distinguish two categories of APIs below.
Here is a summary of the features available in the first category of these APIs.
T his API allows you to create new events and update or delete existing ones. This is actually the same API used by the developers of a Calendar itself. A client application might therefore access any kind of calendar, whether private or public or associated with a group. It allows you to read or publish information from all calendars.
H ere is an API that will be useful for designing applications that manage user accounts. Applications that synchronize Gmail contacts with those in as Smartphone, with a social network, or with a messaging system are examples of applications of this API.
T his API is used for managing a list of Google Documents. A client application using it can search the content in such a list, update its content, or delete it.
T his API is used for accessing the content of a Google Site, for publishing content, or changing it. It is thus possible to design collaborative applications that manage Google Site content. The API also allows you to upload or download documents, to read the history of changes to the site, and even to monitor visits to the site.
APIs in this category are intended mainly for teams that are in charge of Google Apps domain administration (see Chapters 12 to 14) or that want to perform a migration to Gmail from an older messaging system.
T his API can create, update, or delete contacts belonging to the contact list shared by all users. It is also possible to perform searches using a list of criteria.
T his API can help migrate mail data from any source to Gmail. The source can be nearly anything: a mail server, an interface compliant with a messaging protocol, or even the database of a mail client. Each uploaded message can have its label defined as well as its status or its creation date. Tools for both the end user and the administrator are available in this API.
I n complement to the previous API, this one provides access to the Gmail settings for each user. It is thus possible to define preferences for mail transfer, for POP or IMAP, or aliases for mail addresses.
A lso, in complement to the migration API, this one allows you to manage user accounts. Accounts and groups can thus be created programmatically. By synchronizing local data with that of a Google Apps domain, this API can help alleviate mail delivery disruptions during the migration process.