Hailed by some as “replacing IMAP” (good luck with that, Google, if it's your aim), the new Gmail API is more prosaically outlined by the Chocolate Factory's Eric DeFriez in this blog post.
“Designed to let you easily deliver Gmail-enabled features, this new API is a standard Google API, which gives RESTful access to a user’s mailbox under OAuth 2.0 authorization. It supports CRUD operations on true Gmail datatypes such as messages, threads, labels and drafts.”
Why would the world need this? DeFriez again: IMAP “wasn’t really designed to do all of the cool things that you [that is, developers at Google IO] have been working on”.
The Wall Street Journal says, for example, that “A travel app, for example, could scan your email inbox for booking confirmations and automatically compile them into an itinerary. An expense app can dig through your inbox for receipts and automatically file them to your cloud-based account.”
The developer (with permission and authentication, of course), merely needs to send HTTPS calls to the user's mailbox to receive JSON, XML of Google Protobuf responses, “without using a TCP socket, which means the API is accessible from many cloud environments that couldn't support IMAP”.
The API doesn't touch everything the Chocolate Factory can see, but a quick scan shows that it's still pretty comprehensive. Once an app is authenticated to your mailbox it can create and delete messages, or (Vulture South can't imagine this being ever misused) insert a message directly in a target mailbox without actually sending the message from a source.
There's a send method that'll take a message in your inbox and forward it on, there's a method to list all of the labels in a user's inbox, and more. Resource types covered by the API include drafts, history, labels, messages, attachments, and threads.
Google says the API provides fine-grained permissions, so “if your app only needs to send mail on behalf of a user and does not need to read mail, you can limit your permission request to send-only”.
However, as the documentation shows, Google's idea of “fine grained” means there's four permission classes. An app can either:
- Request full access to the target account;
- Request access for everything except the ability to delete messages or threads;
- Read access, but no write or delete rights; or
- Access only to create and send messages and their associated drafts.
In a world a nearly-zero-function app like Yo requests all the permissions the NSA doesn't ask for, that seems unlikely.
El Reg also notes that Android developers have already shown themselves less-than-brilliant at handling OAuth credentials, the basis by which the Gmail API will let developers at inboxes.