Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail API

developers.google.com

Post reply on HN
Print view View original

11–20 of 147 posts

Re: Gmail API

#11

Post by duskwuff »

bpodgursky wrote: post #6

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. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

It doesn't sound as though they're removing IMAP. It's still the recommended API for mail client applications. This API is a new, separate option for applications that don't need access to all your mail.

Re: Gmail API

#12

Post by yogo »

cliveowen wrote: post #5

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.

It would be sweet if email, in general, was just a nice RESTful API.

Re: Gmail API

#13

Post by alooPotato »

bpodgursky wrote: post #6

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. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

I think its pragmatic, IMAP is just so painful.

EDIT: and inefficient

Re: Gmail API

#14

Post by essenobi »

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.

Re: Gmail API

#16

Post by epaulson »

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.

Re: Gmail API

#17

Post by alooPotato »

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature (https://www.streak.com/email-snooze-in-gmail).

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.

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.

Re: Gmail API

#18

Post by mik3y »

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.

Until then I'll probably run out of "quota units" polling the thing..

Re: Gmail API

#19

Post by chimeracoder »

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.

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.

As bpodgursky pointed out, this sentence is troubling:

> 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

Emphasis mine.

[0] I admittedly had no evidence for this speculation before today, just a worry.

Re: Gmail API

#20

Post by vijayaggarwal »

Google has been adding lots of widgets 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.

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.

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.

Post reply on HN