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.