Written by Javier Soltero, June 25, 2014
Today at Google I/O, sandwiched somewhere between smart watches and health monitoring technology, Google announced a new REST API for accessing Gmail. Their choice to highlight an API during their keynote reinforces the strategic importance of Gmail to the company as it continues to aggressively acquire a user base across both consumer and enterprise audiences.
Google’s choice to mention it in the keynote, as did Apple in its WWDC keynote, sparked some interesting conversation at Acompli. Our initial reaction was something like “HUZZAH! NO MORE WHACKY gIMAP!”
But the joy quickly faded as we dug into the specifics. The most obvious question was “Well, what’s changed here? Is this the go-forward API for Gmail/Google Apps?” The quick answer: No. Not yet, at least. This new API is not rich enough to support the capabilities that make Acompli possible. Google clearly includes the “smoking Gmail API Note” in their developer documentation:
Elsewhere on the Internet, the discussion inevitably turned to the issue of standards and how this move represents a move in the wrong direction in preserving the ubiquity of access to email services built on things like IMAP, SMTP, POP3 (gasp!) and a few others.
So, is this a good thing? In short, yes, but it highlights the false promise of the role standards play in the retrieval of email messages. Email standards are the reason why it remains one of the most important and heavily used communications medium in the world. The standards evolved from the early days of the Internet as a set of rules that enable messages to be delivered across arbitrarily complex networks. Unfortunately those standards, and specifically the ones related to retrieving mail (such as IMAP), are quaint by comparison to most APIs developers use these days. Even worse, the standards themselves are all colored with extra elements that make them fundamentally incompatible with each other. In plain English, it means that a Gmail IMAP client and a Yahoo IMAP client are significantly different even though they are both built on a standard.
Fortunately, users don’t care about this kind of stuff. People assume that developers will build email clients and services that can connect to email providers using whatever magic is required, even if it is not built on a standard. The thing they do care about is making sure a message gets delivered and that the recipient can retrieve and read that message. This leads us to the one standard that really does matter: SMTP (Simple Mail Transport Protocol). This standard is responsible for ensuring that email systems can talk to each other and route messages appropriately. It is the binding agreement we all share that makes electronic mail universally reliable and ubiquitous.
Google’s choice to make their Gmail service more accessible to developers through a proprietary API will definitely lead to more innovative uses of email data and possibly new client experiences. This is most certainly a good thing for users, especially since we all depend on email in one way or another. It doesn’t, however, affect the fundamental way in which email travels from one point of the Internet to the other.
The opportunity for dominant email platforms like Gmail and Exchange is to focus on opening up access to developers to build differentiated, powerful experiences that work with the vast amounts of great data in email. If this means the introduction of new APIs, then great. Much like the telephone system and the diversity of handsets and PBXs, there’s ample opportunity to innovate on how users access communication mediums without fundamentally altering the open way in which calls are routed from one system to another. Any step towards making email a more developer-friendly and accessible medium is a step in the right direction, especially for us here at Acompli. Now all we need is for Microsoft to follow suit and simplify and unify their myriad API options for Exchange and Office 365 so we can build even more interesting capabilities with their platform as well.