Integrating with Google APIs: Tips and Tricks, Part 1

Google has more publicly accessible APIs than probably any other software company worldwide. Here's a list of more than 250 Google APIs. We help our customers connect their B2B SaaS products with several of these, including Google Analytics, Gmail, Google Calendar, Google Sheets, Google Cloud Pub/Sub, and more.

We are visiting again with Taylor Reece, a Developer Advocate at Prismatic, to discuss some tips and tricks for developers who need to work with Google APIs. In future discussions, we'll drill down into certain APIs, but this will be an overview of the broader Google API ecosystem.

Bru: Taylor, when we talk about the Google API ecosystem, what is it?

Taylor: Google has perhaps the most complex API ecosystem of any vendor. It has hundreds of APIs, both those that connect with common end-user apps like Gmail and Google Docs as well as special use APIs (such as Google Cloud Pub/Sub) and others such as Google Cloud BigQuery. In some cases, Google has built these systems (including the APIs) from scratch. In other cases, they've bought systems from third parties and reworked the API. Google Analytics is an excellent example of a product Google bought and then substantially reworked.

Bru: Are there some common first steps for devs that need to work with Google's API ecosystem?

Taylor: The first thing you will need is a Google Cloud Platform (GCP) account. You can spin one up for free at https://cloud.google.com. The developer console available in GCP is your gateway to all of Google's APIs, OAuth, and more.

Some of Google's APIs are enabled by default for your account. For others, you may need to search for the service. For example, search for "Google Calendar API" in the developer console, and then click "Enable API."

Once your account is set up and the APIs you require are enabled, head over to the "OAuth consent" page and "Credentials" dev console pages. There, you can add test users for your app, create OAuth 2.0 credentials, service accounts, etc. – everything you need to test your integration as you build it.

Bru: How consistent is Google's approach to APIs across its ecosystem?

Taylor: As you might imagine, there is some variation between Google APIs. Some of this is due to how well an API worked or how mature it was before Google bought it. But some of the variations are because Google is so big that different development teams have different approaches. One example of how things differ across the ecosystem is the inclusion of webhooks for the various systems.

Bru: Would you expand on that? Webhooks are a pretty standard way of sending data updates. How does Google handle them?

Taylor: First, let's define a webhook. A webhook is triggered by an event, resulting in a payload being delivered to an endpoint. For example, a file in Google Drive is modified. The "file modified" event causes an HTTP payload to be sent to an endpoint that you own so you can act on the change. It's a simple way to get immediate notifications of changes.

Webhook implementation varies across Google products. Some have built-in webhook support, others rely on a function that you poll for changes, and others leverage Google Cloud Pub/Sub to notify subscribers of changes.

Bru: Would you help us understand the difference between webhooks and Pub/Sub?

Taylor: Sure. Let's look at two common Google APIs:

When you create a webhook in Google Drive, you instruct Google to notify an endpoint of your choice whenever a change occurs in Drive (maybe a file is updated, created, deleted, etc.). When you receive a notification of the change, though, the notification doesn't include the change that occurred. You then need to reach out to the Google Drive API with a request saying, "The last time I asked for a list of changes, you provided me thus-and-such change token; what changes have occurred since then?" One catch with Google Drive is that you must renew your webhook configuration weekly or daily, depending on the events you're listening for.

Google's Gmail service, on the other hand, leverages Google's Pub/Sub service, which is a full-blown messaging/queuing service. As such, it's more complicated and powerful than webhooks. It requires a publisher (in this case, Gmail), topic (where the messages are stored), and subscription (how data should get to your app). Unlike a simple webhook, Pub/Sub brokers the data instead of passing it from the app to the endpoint. And it can be set up with either a push or pull subscription. A good, detailed explanation of Pub/Sub can be found here.

And, not to confuse matters, a push-type subscription in Pub/Sub can also be a webhook for your app.

Bru. OK. So Google came up with its own message broker that serves the same purpose as webhooks and even supports webhooks in certain instances. But what does that mean in practice? Do all Google products use Pub/Sub for messaging?

Taylor: No. Gmail requires Pub/Sub, but many other Google services can be configured to send messages directly to your API. They can all use Pub/Sub as a message broker, which is handy if you need to notify multiple subscribers that a specific event occurred. Pub/Sub allows you to write a message to a Pub/Sub topic once, and it then publishes notifications to all subscribers of that topic.

Bru: Let's talk a bit about versioning APIs. What are industry best practices?

Taylor: The technology that underlies APIs is always changing. For example, API security needs are constantly under review. So, it makes sense that APIs must be upgraded and versioned (if the upgrade is substantial enough). When this happens, most vendors think about how they can make their latest version backward compatible, so it doesn't break all the apps and services connected to the prior version of the API. New versions of APIs are often not 100% backward compatible, but they usually manage to be backward compatible with the critical functionality that most developers are using.

Bru: Somehow, I'm guessing that Google does things differently.

Taylor: Yes. Google takes a different approach than most other vendors. It is common for specific versions of Google APIs to be deprecated in as little as two or three years, and sometimes even faster than that. In some cases, this makes sense – such as when a major security issue has been discovered. But in many cases, these deprecations don't seem to make sense to the broader community. And Google does not always ensure backward compatibility with new versions of APIs.

Bru: So Google isn't greatly concerned about backward compatibility with its APIs. Do you know why that is?

Taylor: Well, maintaining backward compatibility takes a truckload of development time. And Google has a lot of APIs. Given Google's absolute dominance in several markets, it's not as though devs will stop using Google APIs because the latest version broke backward compatibility. I'd say that most devs have just learned that it's something they must deal with when using Google APIs. However, our embedded iPaaS can make staying current with Google API releases much easier for your devs. We keep our API connectors up to date with the latest versions of Google APIs, so our customers don't need to.

Bru: And that brings us to the end of Part 1 of using Google APIs for integrations. Thank you, Taylor. We'll get into more Google API details in Part 2.

Schedule a demo to see how Prismatic makes it easy to use Google APIs to build integrations with your B2B SaaS product.