Over the course of the next few months, we're going to look in depth at how to integrate Google web applications, like Calendar or Contacts, into your own web applications. If your app requires calendaring capabilities, for example, you can just use Google Calendar instead rolling your own calendar. Your app can create, read, or modify specific calendars within Google Calendar, or even access all of them if that's necessary. This mash-up approach has several advantages: Your users get a UI that's already familiar; they need to maintain only one calendar that can encompass their entire life (rather than several calendars, one for each application), and they can easily access the calendar functions from cell phone.. In the case of Google Docs integration, you can offload your document-storage issues to Google, including the physical space required to hold the documents.
There is a downside. If Google Calendar goes down, so does your application. If your users prefer iCal or Outlook, then you're in the position of reconciling different calendar applications or supporting all of them. The reconciliation process isn't too bad with calendars, all of which are pretty much the same, but it's a nightmare with Contacts.
In terms of the user experience, learning how to master a new UI is a significant barrier to adoption, so letting your customers use familiar applications to do familiar things is a very good thing. More to the point, you can probably write integration code for three separate calendars in less time than it would take to build a high quality calendering system. In fact, in the case of calendars, you can get away with implementing CalDAV (IETF RFC 4791), and integrating it with just about everybody. Unfortunately, there isn't an IETF standard that gives you access to the other Google services, so we need to know how to do things in a Google world, too.
Authentication
The one requirement that all Google services impose is authentication. Although you can access all the services with a Google username and password, most of your users will be unwilling to let you have that much access. A better approach is for your users to tell Google exactly which services they'll allow your app to touch. In fact, even finer granularity is possible — they could restrict access to a single calendar, for example. Google actually provides two mechanisms for doing that. There's an older mechanism called AuthSub, but Google has effectively deprecated that protocol in favor of OAuth — an open protocol that's not at all Google specific. (The main website for the OAuth project is OAuth.net. The Beginners Guide to OAuth is particularly helpful, and is better than the introductory documentation on Google's site.)
This month, I'll go over the OAuth protocol, noting the things you need to do to get started, and I'll also discuss several security issues. Next month, I'll present a complete example of the entire authorization process. If you're in a hurry, Google provides samples of the essential code here, but those examples are just out-of-context snippets (in Java, Python, and PHP). Also, Google's article, Using OAuth with the Google Data APIs, describes the HTTP/REST protocol that underlies the high-level-language implementations, and demonstrates how to use Google's OAuth Playground, which lets you walk through the actual process manually. Exercising the actual protocol manually will make my explanations a little easier to absorb.
Setting up Google Apps
The first thing we'll need to do is set up a Google Apps account. via the link at http://www.google.com/apps/. If you haven't explored Google Apps, you should spend a few minutes looking it over. Google Apps lets you support various Google services (like Calendar and GMail) using your own domain name rather than google.com. Even if you use if for nothing else, I'd honestly recommend that you use Google Apps for email so that you can use a real email address (me@myDomain.com) rather than a Micky-Mouse me@gmail.com address. Most small companies are better off using Apps to manage their email than doing it via an ISP — it has more useful features. For one thing, Google has, by far, the best spam filtering out there, and forwarding your email from an ISP service to GMail to do spam filtering doesn't work very well because Google will most likely decide that your domain (from which the email is forwarded) is a spammer. When you set up Google Apps for email support, you modify your DNS record so that email sent to your domain is forwarded directly to Google rather than to your ISP. (The part of the DNS record that points to your website is unaffected by this change.)
Google Apps accounts come in two flavors: free, which will work fine for the moment; and "for Business," which costs $50 per user account per year. (Think of a user account as an email in-box.) There are a few advantages to actually paying: You get 24x7 technical support, a 99.9% uptime SLA, better spam filtering than GMail, and more storage for things like email. You also get a guarantee that Google won't lose all your saved email (which has happened to friends of mine who had normal GMail accounts). The other advantage of paying for the service is that Google provides a few apps that aren't generally available. The free account provides customized-to-your-domain versions of email (GMail), Docs, Groups, Chat, Contacts, and Sites — the basic facilities that are provided to every Google account. Paid accounts add video (effectively domain-specific YouTube), Postini (which adds things like virus detection, black-list blocking, email-encryption services, and rapid failover in the event of a email-server crash), and a version of Wave (a pretty useful, though soon to be unsupported, collaborative-workflow tool that I rather like. It lets several people who aren't in the same physical location simultaneously edit a shared document while on a conference call, for example).
A Few Terms
Before moving on, I need to introduce some vocabulary; see Table 1.
