We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature (<a href="https://www.streak.com/email-snooze-in-gmail" rel="nofollow">https://www.streak.com/email-snooze-in-gmail</a>).<p>The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases.<p>The reason its hard (currently) to build a mail client using the API is that call to list the threads in your inbox or any other label doesn't actually return the messages in those threads. So its hard to show the people that are on the thread as well as some of the timestamp. If they added some more summary data to the thread object, I could see this becoming feasible.
I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications.<p>Edit: I'm going off of this sentence:<p>>It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail<p>Maybe it's misleading, but it sounds like the plan is to drop support.
Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.
I can't believe how many people are stoked about this. If you look at <a href="https://developers.google.com/gmail/api/auth/scopes" rel="nofollow">https://developers.google.com/gmail/api/auth/scopes</a>, basically apps can do a combination of a) have full control, b) read everything, c) do everything but delete emails, or d) read/write/send drafts.<p>Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents in the future.
I'm not sure what this API enables that can't be done over IMAP. IMAP may not be as familiar as JSON-over-REST, but it's supported by virtually all mail clients and providers, which makes it about as open as you can get.<p>Already the Gmail IMAP implementation is non-standard in a number of annoying-but-workable ways. I've been suspecting for a while that they're going to kill it or lock it down, the way they did for XMPP and Talk[0]. I really hope this isn't the first step towards that.<p>As bpodgursky pointed out, this sentence is troubling:<p>> It will <i>replace</i> IMAP, a common but complex way for applications to communicate with most email services, <i>limiting the number of apps that can work with Gmail</i><p>Emphasis mine.<p>[0] I admittedly had no evidence for this speculation before today, just a worry.
Two key bits from the first two paragraphs of the article:<p>"make it easier for other Internet applications to use information in your email"<p>"It will replace IMAP"<p>First one seems par for the course, the second one doesn't seem to be reflected in the Google blog post [1]. Certainly for the moment, thankfully, it looks like IMAP is staying:<p>"The Gmail API should not be used to replace IMAP for full-fledged email client access" [2]<p>[1] <a href="http://googleappsdeveloper.blogspot.com/2014/06/introducing-new-gmail-api.html" rel="nofollow">http://googleappsdeveloper.blogspot.com/2014/06/introducing-...</a>
[2] <a href="https://developers.google.com/gmail/api/" rel="nofollow">https://developers.google.com/gmail/api/</a>
It would take something pretty amazing for me to allow anyone access to my gmail account. LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.
This might be big, I was just done complaining about the user interface of the GMail web app. If this means that developers can now effectively create another interface on top of a real GMail API this has the potential to really change things. I can already envision several ways in how I could improve my inbox management and reduce the time spent sifting through emails.
My killer app for this needs webhooks, or some sort of event notification when mail arrives. Bonus points for making that condition a stored procedure/filter.<p>Until then I'll probably run out of "quota units" polling the thing..
If they can combine this ease of accessibility for developers with a security model on the end-user side, I think it can be a solid win.<p>I'd love to see granularity in what the API can access, for example, TripIt may request something like "Grant access to emails from the domain travelocity.com, usairways.com, etc.," and I can know with confidence that they will not have access to the rest of my inbox.
It's high time that we get user-controlled sandboxes that could enforce additional security restrictions and are application-transparent. If a third party app requires access (R/W) to my Google Drive files, I should be able to limit said access to a single folder, for instance, and any other content should simply be invisible to it. These restrictions should be tuneable at any time (before and after app install) and there should be visualization tools to control their effectiveness.
Google has been adding lots of <i>widgets</i> to email recently, like RSVP on invitations, itinerary on flight booking emails, etc. These are pretty useful features and I believe a lot more are possible with the APIs being opened.<p>However, I feel the access control is very coarse grained. For example, RSVP widget needs access to only event related emails and itinerary needs only travel booking emails, but the API spec does not allow for such fine grained control.<p>IMO, given that google is able bucket-ize emails into travel booking, event, etc., and even user-defined labels for any custom grouping, allowing access on such buckets would be nearly as useful and much more user-privacy friendly. For example, an accounting app could still access invoices from my inbox to update my accounts automatically. Google could even push for microformats kind of annotation to make emails semantically richer.
We (<a href="http://grexit.com" rel="nofollow">http://grexit.com</a>) let users share Gmail labels. We're very happy to see this release as it has been a pain to build and scale our service over IMAP.<p>It'd be interesting to see what kind of limits (no. of calls, concurrency etc.) that Google has put on the API. Has anyone trying this out hit of any of these issues yet?
This raises serious privacy concerns for me.<p>Technical users can and will block access to portions of the API during authenticatcaion, but what about people like my parents? They might very well login, giving full permissions to the app, seeing that it's a trusted google URL while not knowing what they have done.<p>This is going to open a new can of worms.
I see that as being a great opportunity for customer referrals. So many people have a gmail account. It'd be cool, from the business' standpoint, to see if your customers are connected through something as simple as email if they allow an app to access sender information.
This is fantastic. What we need next are OAuth libraries for Postfix and other SMTP servers, so I can use Gmail to centralize and read my email but still use my home organization's SMTP server to send email, without having to give Google a copy of my password.
This looks like it'd be EXTREMELY useful for cronjobs and other things where you need to send email to yourself (or another address) automatically. It would remove the need to self-host email just so that you can send status reports...
Great idea. I only wish it was an open standard... Email success b/c of it openness, but if we start proprietary APIs on top of it then we are getting locked in.
Here is the actual Google blog post: <a href="http://googleappsdeveloper.blogspot.com.ar/2014/06/introducing-new-gmail-api.html" rel="nofollow">http://googleappsdeveloper.blogspot.com.ar/2014/06/introduci...</a>
The article is light on the technical details.
Here's the API: <a href="https://developers.google.com/gmail/api/" rel="nofollow">https://developers.google.com/gmail/api/</a>
We changed the url from <a href="http://online.wsj.com/news/article_email/google-opens-gmail-making-it-more-of-a-platform-for-developers-1403719202-lMyQjAxMTA0MDIwNTEyNDUyWj" rel="nofollow">http://online.wsj.com/news/article_email/google-opens-gmail-...</a>.
Hot off the presses! Google just released the latest future ex-api they will get bored of in a couple/few years and kill, along with any company that depends on it. #rememberthiscommentthen