The New Gmail Api

JOHN RAE-GRANT: Hi, I'm John Rae-Grant, product manager for Gmail Extensibility. I'm here to talk about the new Gmail API. Let's start with a quick history lesson. Back in the midst of the distant past, there was email. Many email systems were closed, meaning that you had to use a specific application or a specific website to manage your mail. This made it hard for people who had multiple accounts or multiple clients to manage their mail. So IMAP was born. IMAP is a standard protocol designed for an email client to connect to an email server. IMAP's great, because it means that we can do cool things like get all of our mail into one inbox or send email using any of our accounts from the same client. So IMAP was designed to enable a full-fledged email client to connect to an email service. Gmail initially introduced IMAP support in 2007, specifically with the goal of making it easy to use mobile device email apps to access your Gmail account. And it was good. Then things got interesting. Once Gmail opened up to IMAP, the developer community realized there was now a way to enable users to add features that used their Gmail data. These developers, you folks, went way beyond building simple email clients. You did brilliant things, like adding a record of messages exchanged with each prospect to a CRM system. You made useful utilities, which manage your email subscriptions or allow you to send mail at a later date. You even wrote custom Chrome extensions which talk to IMAP and extend the Gmail UI. All of these are good things. So what's the problem with IMAP? Well, IMAP's great, but Gmail and you have gone way beyond what it was designed for. IMAP was designed a long time ago. Originally, in 1986, with the last major core protocol version in 1998. To give some context, that's the year the Sony PlayStation was battling it out with the Nintendo 64 and a new search engine called Google first launched. APIs have come a long way since then. IMAP was designed to handle the kind of mailboxes people used to have. It was never intended to scale to hundreds of thousands of messages in an inbox. In 2004, Gmail revolutionized the inbox by giving you one gigabyte of storage, giving you the ability to stop wasting time sorting folders and instead use powerful queries to search labels. Despite the decade since IMAP was introduced, it still doesn't have standards to support the revolutionary way Gmail interacted with users a decade ago, let alone our many improvements since then. It's not that IMAP isn't useful. It's that it's getting used in ways for which it wasn't designed, sort of like this golf club. You can use it for bowling, and since you're clever and determined you might manage to knock down some pins, but it's not really the right tool. So we're introducing the new Gmail API to enable you all to creatively meet the modern use cases of today's users. We've kept in mind all the performance and ease of use that you'd expect to come with that. The new Gmail API provides very simply what you would expect, with RESTful access to threads, messages, and labels, including drafts. In contrast to IMAP, which requires access to all of the user's messages for all operations, the new API gives fine grained control to the user's mailbox. If you just need to send mail as a convenience from your app, you don't need to ask the user for permission to read mail. To keep in sync, the API allows you to query the inbox change history, thereby avoiding the need to pull or do archaeology to figure out what changed. Most importantly, this API is designed to make it easy and efficient to do specific queries, such as get me all the messages exchanged with Joe. Or get all the messages received with the my_company label. Or get me all the messages in this thread. Essentially, the API offers the full search capabilities of the web UI using the same syntax as the search box. Since the new Gmail API is a standard Google API, you get simple HTTPS access using RESTful calls and get your responses in JSON, XML, or Google Protobuf formats. You can also make these calls from standard web languages like Java and Python. And there's no need for a TCP socket. This means that the API is accessible from many cloud environments that couldn't support IMAP. Not only does the new API replace IMAP for many applications, it also replaces SMTP for mail sending. And one huge advantage is speed. As I mentioned earlier, IMAP was never designed to do what you've been getting it to do. Because the new Gmail API was designed for the Gmail backend architecture, it understands labels instead of folders and is optimized for exactly these operations. Here are some preliminary speed tests which demonstrate that even before the tuning, which you beta users will be helping us to do, the Gmail API handles getting a thread or doing a search for matching messages a factor of three to 10 times faster than IMAP. Since the new Gmail API is a standard Google Developer API, you'll be able to get started right away using the same developer key and developer console that you already use for other Google APIs. All access is under standard OAuth 2.0 authentication, so you've likely already done that as well. If you haven't, the example apps and SDK documentation have done most of the work for you. The Gmail API is entering beta the week of June 24, 2014. We're really eager to get your suggestions and feedback. To get started, go to the Google Developers site and follow the instructions to sign up for the beta. And we'd love to hear your feedback and suggestions. On behalf of the Gmail team, thanks for your attention. And we can't wait to see what you'll make with the new Gmail API.