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, meaningthat you had to use a
specific applicationor a specific website
to manage your mail. This made it hard for people
who had multiple accountsor multiple clients
to manage their mail. So IMAP was born. IMAP is a standard protocol
designed for an email clientto connect to an email server. IMAP’s great, because
it means that wecan do cool things like get
all of our mail into one inboxor send email using any of our
accounts from the same client. So IMAP was designed to
enable a full-fledged emailclient to connect
to an email service. Gmail initially introduced
IMAP support in 2007,specifically with
the goal of makingit easy to use mobile device
email apps to access your Gmailaccount. And it was good. Then things got interesting. Once Gmail opened up to
IMAP, the developer communityrealized there was now
a way to enable usersto add features that
used their Gmail data. These developers,
you folks, went waybeyond building
simple email clients. You did brilliant things, like
adding a record of messagesexchanged with each
prospect to a CRM system. You made useful utilities, which
manage your email subscriptionsor allow you to send
mail at a later date. You even wrote custom
Chrome extensionswhich 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 youhave gone way beyond
what it was designed for. IMAP was designed
a long time ago. Originally, in 1986, with
the last major core protocolversion in 1998. To give some context, that’s the
year the Sony PlayStation wasbattling it out
with the Nintendo64 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 usedto have. It was never intended to
scale to hundreds of thousandsof messages in an inbox. In 2004, Gmail
revolutionized the inboxby giving you one
gigabyte of storage,giving you the ability to stop
wasting time sorting foldersand instead use powerful
queries to search labels. Despite the decade since
IMAP was introduced,it still doesn’t have
standards to supportthe revolutionary way
Gmail interacted with usersa 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’tdesigned, sort of
like this golf club. You can use it for
bowling, and since you’reclever 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 APIto enable you all to
creatively meet the modern usecases of today’s users. We’ve kept in mind
all the performanceand ease of use that you’d
expect to come with that. The new Gmail API
provides very simplywhat you would expect, with
RESTful access to threads,messages, and labels,
including drafts. In contrast to IMAP,
which requires accessto 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 changehistory, thereby avoiding the
need to pull or do archaeologyto figure out what changed. Most importantly,
this API is designedto 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 searchcapabilities of the web
UI using the same syntaxas the search box. Since the new Gmail API
is a standard Google API,you get simple HTTPS
access using RESTful callsand get your responses in
JSON, XML, or Google Protobufformats. You can also make these calls
from standard web languageslike Java and Python. And there’s no need
for a TCP socket. This means that the API is
accessible from many cloudenvironments that
couldn’t support IMAP. Not only does the
new API replaceIMAP for many
applications, it alsoreplaces SMTP for mail sending. And one huge advantage is speed. As I mentioned
earlier, IMAP was neverdesigned to do what you’ve
been getting it to do. Because the new Gmail API
was designed for the Gmailbackend architecture,
it understandslabels instead of
folders and is optimizedfor exactly these operations. Here are some
preliminary speed testswhich demonstrate that even
before the tuning, whichyou beta users will
be helping us to do,the Gmail API handles
getting a threador doing a search
for matching messagesa 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 usingthe same developer key
and developer consolethat 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 documentationhave 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 siteand 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’llmake with the new Gmail API.