7 ms·

Google Drive Realtime API

136 points by noinput 14y ago

polskibus 14y ago
I'm still irritated with Google Reader story. How long is this one going to be around, year, two? I think Google should start pledging a number of years they will support a service, why should the developer be taking most of the risk?
- ewolf 14y ago
  There never was any official Google Reader API. Every developer was aware of the risk he was taking when using an unoffical and undocumented API.
- mgkimsal 14y ago
  That's actually a good point. Giving people a "minimum guaranteed time" for APIs and services would give a lot more confidence to people looking to build on them, and also keep data portability at top of mind when building on those services.
  - polskibus 14y ago
    I'm pretty sure they already know the minimum time they want to keep a certain service afloat. Would they really lose much if they publicly announced a date, after which they would reevaluate a service? I think I'm giving Google free PR advice here... damn you Google!
  - arkem 14y ago
    Some of Google's API do have this, it'll be in their terms of service under "Deprecation Policy". The deprecation policy is a promise that if the service is going to be discontinued you'll have at least X notice. The examples I can think of off hand are all Google App Engine related but I wouldn't be surprised if some of the Drive APIs have the same thing.
- yanw 14y ago
  Reader didn't have a documented API, and the differences between it and this only begin there. Move on.
  - jerhinesmith 14y ago
    I'm not the OP, but I don't think he was necessarily talking about the Google Reader API (rather just the service). If you're getting hung up on documented/undocumented APIs, pick any one of the deprecated examples from this list (http://googlecode.blogspot.com/2011/05/spring-cleaning-for-some-of-our-apis.html http://googlecode.blogspot.com/2011/05/spring-cleaning-for-s...) and substitute it in for Google Reader.
    - polskibus 14y ago
      I was talking about the service, it doesn't really matter for the user if it's in a form of API or not. I do "PAY" google with my wasted brainpower when I see ads they serve (adblock possibility aside). Seriously though, there's nothing free but it works both ways, it's only fair and long lasting when both sides treat the arrangement as a contract.
      - tomkarlo 14y ago
        How is that arrangement a contract? If you came to Starbucks every morning and bought a cup of coffee, would you consider that to be creating some kind of contract with them?
    - yanw 14y ago
      https://news.ycombinator.com/item?id=5403668 https://news.ycombinator.com/item?id=5403668
  - anon1385 14y ago
    Oh so Google never cans a free service that has an official documented API? Google Translate? Google Search API? >Move on. Yes, let's just forget about all the stuff Google does that sucks and pretend it never happened.
- 616c 14y ago
  They plan on charging people for Drive space, so I see the underlying storage as a Dropbox competitor while the convenience of online collaboration tools and document editing meant to push them out, as it is heavily integrated into other Google services. https://support.google.com/drive/bin/answer.py?hl=en&answer=2375123 https://support.google.com/drive/bin/answer.py?hl=en&ans...
- tomkarlo 14y ago
  Isn't this the risk any time you build on top of someone's API? At least with Google Drive they have a clear revenue story - compare that to say, Twitter.
- notatoad 14y ago
  Don't build a business or product that relies on a proprietary API with no service agreement. APIs with no service agreement are okay if they're well-documented and have multiple providers, proprietary APIs are fine if they have a service agreement. Something like this should not be used as the base for your product, it should only be used as a means to provide an extra feature to an existing service. This is allows you to integrate your real-time web application with drive, it's not a foundation to build your real-time service on top of. Just because google shut down reader doesn't mean that this applies to their APIs more than any other company's. If you build something that relies on an API that can disappear at any time, you have nobody to blame but yourself.
- hugofirth 14y ago
  Ugh - people should just LET READER GO. Here we have what looks like a cool, well documented, API to a powerful service supported by a major company and instead of talking about the cool things we could build with it we seem to be indulging in that most deplorable and pointless of past times - the fan boy cat fight. This is still called "Hacker" news correct? FYI the translate API is paid - not retired. The rates are very low and free for limited use. Furthermore CalDAV was one of the worst things I have ever had the displeasure to work with - why are we mourning that ? Now - can we please talk about something worthwhile like ... Oh! ... the OP /rant
  - Samuel_Michon 14y ago
    "Ugh - people should just LET READER GO." Yeah, it's been 6 whole days! Some people really dwell in the past, don't they? I don't see what the big deal is, especially since Google has already given us something way better, which will replace RSS, Twitter, Facebook, and probably email – in a couple of months everyone will be using Google+ and we'll have forgotten all about Reader.
    - ancarda 14y ago
      How is Google+ a replacement for RSS?
      - camus 14y ago
        he was being sarcastic ;)
    - hugofirth 14y ago
      You talk like its a person - it's a damned service ... Plus my point was that the demise of Reader had nothing to do with the OP, and that its continued discussion in any post containing the letter G was pathetic, detracting from more interesting conversations we could and should be having - like the one about the possibilities of the new Drive API... I'm tired of the railroading and the assumption that a for-profit organization has some sacred duty to think about anything more than its bottom-line. That Google thinks beyond its bottom line quit often (Glass, Cars etc...) is to its credit - IMO that it does not do so all the time (Wave, Buzz, Video, Reader etc...) is NOT to its discredit.
- guptaneil 14y ago
  The self-fulfilling prophecy[1] is a powerful phenomenon. If Google pledges 3 years support, then I will assume it's going to be killed in 3 years and not even bother trying to build a business on it, even though Google only means that as a minimum. If everybody assumes the same, then the API probably will end up dead in 3 years, because nobody is using it. On the other hand, since Google makes no such pledge, I don't feel like this API has an expiration date. Instead, I look at this as Google's latest product, and I might want to be the first to integrate it into my service, because it could be the next big thing. If enough people think that way, then the API will thrive and stick around. Sure, the API could still disappear, but any startup built on it has a greater chance of dying before the API does. Google's problem right now is that it has pissed off a vocal minority with the Google Reader shutdown, so any announcement is being met with pessimism and mistrust. 1: http://en.wikipedia.org/wiki/Self-fulfilling_prophecy http://en.wikipedia.org/wiki/Self-fulfilling_prophecy
  - polskibus 14y ago
    No expiration date is just an evil omission. The risk is of obsolescence is there, whether they state the date or not. Making the risk visible to everyone makes the situation clearer for everyone. All that is needed is a table like http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173 http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173
clarle 14y ago
This is pretty awesome. It seems like the models are similar to the operational transformation models that they've been using in Wave/Docs (with the batched client operation submissions). It's definitely much more advanced than what Meteor does, which is just last-writer-wins. Still, I'm a bit wary that they're offering this as a API, rather than a framework. I don't know if I would build an application completely on top of an external API...
- boucher 14y ago
  Given that it seems to require building everything on the three collaborative primitives, and that much of Wave and the ideas behind operation transformations are open, it seems plausible that someone could build an open source implementation of the server component that the JavaScript library could then hook into.
  - josephg 14y ago
    I'm the developer of ShareJS (sharejs.org) - and we have realtime JSON editing too. The technology is compatible, and it should be pretty easy to make ShareJS compatible with the GDrive client API.
sylvainstudiogd 14y ago
They should fix Google drive before launching an api... I don't understand why google didn't fix it yet. It's a big issue, bigger than the google reader thing... People use Google drive for their business (and some pay, like me), not google reader. WTF Google ! We are waiting so long !
- jcomis 14y ago
  Forgive my ignorance, but what is the problem you are referring to?
- ChrisClark 14y ago
  Fix what part of it? You're talking as if we all know what is wrong and needs to be fixed but I don't think we know what you are referring to. Google Drive works great for everyone I know, are you referring to the short downtime the other day?
  - d--b 14y ago
    The sync is broken. It perpetually needs to be restarted on the desktop. Combine this with 2-steps authentication and you have to send yourself 3 messages per day to make this work.
  - sylvainstudiogd 14y ago
    Sorry yes I assumed everybody knows because I know many people having problem around me... The famous unsyncable file, everybody I know including me have this issue. For some people Google drive use 100% of the cpu until it crashes, always, whatever they try. I got often disconnected for absolutly no reason. Well, I have collegueS that just can't make it work on their computers (recent iMac and macBook). And When I search on google, i find easily many people having the same problems, even today. I love Google product, but currently Google Drive is huge fail for me, I hope they fix it soon. They didn't update their app since a long time I think...
    - ChrisClark 14y ago
      I think that seems to be a common problem with Google. It could be only 1% of people are having the trouble you are having. But that could mean 10,000 people(not sure about real numbers) but at 1% it isn't on Google's priority list. :(
julien 14y ago
Wasn't Google killing Reader because they had to focus on less products? How many new products this week alone have they introduced? 3, 4, 5?
- yanw 14y ago
  No, they added 3,4,5 features to existing products, and it's fairly obvious that I'm not sure if you're trolling or not.
- smogzer 14y ago
  Google closing reader was probably something to do with the French un-digital papers that wanted the interwebs going to their website-o-pages to read content there.
resu_nimda 14y ago
This is slightly off-topic, but since everybody's commenting about it anyway: Was Google Reader (and Posterous, to a lesser extent) the tipping point for awareness and activism surrounding the shutdown of free services? This could be a big thing in 2013.
- brianwillis 14y ago
  The tipping point for me was Twitter's increasingly hostile approach to third party devs. I've been racking my brain trying to think of the first service that I used regularly that was shut down. Pownce maybe? (anyone else remember that?). I'm currently hunting for a replacement for Gmail that is self-hosted, or at least a solution where the cost of switching providers is low (i.e. I could shift my email to a new host without changing my email address or losing my message history). I'll probably end up using some sort of IMAP provider. There are a lot of features I'd stand to lose though. Conversation view is hugely useful, and Gmail's spam filter is just unbeatable.
  - xcasex 14y ago
    pownce was indeed awesome. both twitter and in some part google have recently acted very hostile to the notion of the open web. (Although referring to corporations as a singular entity irks me somewhat)
anonfunction 14y ago
This is really a great API for developers and I can see a lot of different applications. Let's not let google reader's closing negate all the tools google provides for free.
pak 14y ago
Assuming I trust Google with all the data and all my users have Google Drive, this looks like a super easy way to make documents created in a web app editable in real time by multiple users. I'm curious about the details though, which would be ironed out with some more detailed playground examples. Does the API handle merging of the update events on the client side, or do I have to do all that work myself from the stream of insert/removal events? Can I handle them myself if I want? Assuming I want to extend the UI of these updatable strings, so that people can see other people's cursors and such, what would I need to do? Is the client-side library extendable so it can update my UI without hammering my customizations (cursor position, formatting, embedded data transformed into HTML)? How will that scale once the document grows to a considerable size (will I be able to update only changed portions of the DOM created by a large document without doing my own complex diffing logic on the client side)? For example, build me a basic rich text editor in this that mimicks some of the features of Docs, and show me how much extra code that takes. This code sample by itself doesn't make me confident that the above features would be simple: https://github.com/googledrive/realtime-playground/blob/master/js/rtpg.string.js https://github.com/googledrive/realtime-playground/blob/mast... It's precisely those richer features of the Google Docs experience that people crave when they say they want to add "realtime collaboration" to an app, not just .val()'ing form fields to the latest known value from the server. Right now this looks like it has the features of a backbone.js + Couch adapter (e.g., http://janmonschke.com/projects/backbone-couchdb.html http://janmonschke.com/projects/backbone-couchdb.html) except Google sits on all my data.
sylvinus 14y ago
I really thought this was an API for the driverless cars! Slight disappointment after following the link of course :)
deleted 14y ago
[deleted]
vineet 14y ago
The API seems to require users (and not just developers) to have to authorize the app :-( This kinda limits you to Google Docs style apps, as opposed to other crazy ideas I might have. I would also like to have an option to pay so that I can keep our users data private. Edit: Added clarification.
- poundy 14y ago
  Is there a way let users collaborate without authorizing the app? Developers authorize and create API with Google but it will be nice to allow users to collaborate anonymously like Sharing a Google Doc to the public.
msutherl 14y ago
Would it be possible, with this, to display files in your Google drive as read-only to people visiting a website? I'm thinking this would make a killer back-end for certain kinds of websites.
deleted 14y ago
[deleted]
chenster 14y ago
More importantly, how does Google ensure me it won't shut it down in 5 years?
rtexal 14y ago
Wondering if Google Keep (http://www.theverge.com/2013/3/17/4117780/google-keep-note-taking-app-spotted-in-drive-before-disappearing http://www.theverge.com/2013/3/17/4117780/google-keep-note-t...) is built on top this API ;) The API realtime capabilities will definitely drive interesting projects if Google Keep is just the start!
anonfunction 14y ago
Anyone have a good source for a list of all the official and unofficial google APIs? A quick search provided this but it does not have any of the unofficial internal API's that we love so much. https://developers.google.com/apis-explorer/ https://developers.google.com/apis-explorer/

136 points by noinput 14y ago

I'm still irritated with Google Reader story. How long is this one going to be around, year, two? I think Google should start pledging a number of years they will support a service, why should the developer be taking most of the risk?

ewolf 14y ago
There never was any official Google Reader API. Every developer was aware of the risk he was taking when using an unoffical and undocumented API.
mgkimsal 14y ago
That's actually a good point. Giving people a "minimum guaranteed time" for APIs and services would give a lot more confidence to people looking to build on them, and also keep data portability at top of mind when building on those services.
- polskibus 14y ago
  I'm pretty sure they already know the minimum time they want to keep a certain service afloat. Would they really lose much if they publicly announced a date, after which they would reevaluate a service? I think I'm giving Google free PR advice here... damn you Google!
- arkem 14y ago
  Some of Google's API do have this, it'll be in their terms of service under "Deprecation Policy". The deprecation policy is a promise that if the service is going to be discontinued you'll have at least X notice. The examples I can think of off hand are all Google App Engine related but I wouldn't be surprised if some of the Drive APIs have the same thing.
yanw 14y ago
Reader didn't have a documented API, and the differences between it and this only begin there. Move on.
- jerhinesmith 14y ago
  I'm not the OP, but I don't think he was necessarily talking about the Google Reader API (rather just the service). If you're getting hung up on documented/undocumented APIs, pick any one of the deprecated examples from this list (http://googlecode.blogspot.com/2011/05/spring-cleaning-for-some-of-our-apis.html http://googlecode.blogspot.com/2011/05/spring-cleaning-for-s...) and substitute it in for Google Reader.
  - polskibus 14y ago
    I was talking about the service, it doesn't really matter for the user if it's in a form of API or not. I do "PAY" google with my wasted brainpower when I see ads they serve (adblock possibility aside). Seriously though, there's nothing free but it works both ways, it's only fair and long lasting when both sides treat the arrangement as a contract.
    - tomkarlo 14y ago
      How is that arrangement a contract? If you came to Starbucks every morning and bought a cup of coffee, would you consider that to be creating some kind of contract with them?
  - yanw 14y ago
    https://news.ycombinator.com/item?id=5403668 https://news.ycombinator.com/item?id=5403668
- anon1385 14y ago
  Oh so Google never cans a free service that has an official documented API? Google Translate? Google Search API? >Move on. Yes, let's just forget about all the stuff Google does that sucks and pretend it never happened.
616c 14y ago
They plan on charging people for Drive space, so I see the underlying storage as a Dropbox competitor while the convenience of online collaboration tools and document editing meant to push them out, as it is heavily integrated into other Google services. https://support.google.com/drive/bin/answer.py?hl=en&answer=2375123 https://support.google.com/drive/bin/answer.py?hl=en&ans...
tomkarlo 14y ago
Isn't this the risk any time you build on top of someone's API? At least with Google Drive they have a clear revenue story - compare that to say, Twitter.
notatoad 14y ago
Don't build a business or product that relies on a proprietary API with no service agreement. APIs with no service agreement are okay if they're well-documented and have multiple providers, proprietary APIs are fine if they have a service agreement. Something like this should not be used as the base for your product, it should only be used as a means to provide an extra feature to an existing service. This is allows you to integrate your real-time web application with drive, it's not a foundation to build your real-time service on top of. Just because google shut down reader doesn't mean that this applies to their APIs more than any other company's. If you build something that relies on an API that can disappear at any time, you have nobody to blame but yourself.
hugofirth 14y ago
Ugh - people should just LET READER GO. Here we have what looks like a cool, well documented, API to a powerful service supported by a major company and instead of talking about the cool things we could build with it we seem to be indulging in that most deplorable and pointless of past times - the fan boy cat fight. This is still called "Hacker" news correct? FYI the translate API is paid - not retired. The rates are very low and free for limited use. Furthermore CalDAV was one of the worst things I have ever had the displeasure to work with - why are we mourning that ? Now - can we please talk about something worthwhile like ... Oh! ... the OP /rant
- Samuel_Michon 14y ago
  "Ugh - people should just LET READER GO." Yeah, it's been 6 whole days! Some people really dwell in the past, don't they? I don't see what the big deal is, especially since Google has already given us something way better, which will replace RSS, Twitter, Facebook, and probably email – in a couple of months everyone will be using Google+ and we'll have forgotten all about Reader.
  - ancarda 14y ago
    How is Google+ a replacement for RSS?
    - camus 14y ago
      he was being sarcastic ;)
  - hugofirth 14y ago
    You talk like its a person - it's a damned service ... Plus my point was that the demise of Reader had nothing to do with the OP, and that its continued discussion in any post containing the letter G was pathetic, detracting from more interesting conversations we could and should be having - like the one about the possibilities of the new Drive API... I'm tired of the railroading and the assumption that a for-profit organization has some sacred duty to think about anything more than its bottom-line. That Google thinks beyond its bottom line quit often (Glass, Cars etc...) is to its credit - IMO that it does not do so all the time (Wave, Buzz, Video, Reader etc...) is NOT to its discredit.
guptaneil 14y ago
The self-fulfilling prophecy[1] is a powerful phenomenon. If Google pledges 3 years support, then I will assume it's going to be killed in 3 years and not even bother trying to build a business on it, even though Google only means that as a minimum. If everybody assumes the same, then the API probably will end up dead in 3 years, because nobody is using it. On the other hand, since Google makes no such pledge, I don't feel like this API has an expiration date. Instead, I look at this as Google's latest product, and I might want to be the first to integrate it into my service, because it could be the next big thing. If enough people think that way, then the API will thrive and stick around. Sure, the API could still disappear, but any startup built on it has a greater chance of dying before the API does. Google's problem right now is that it has pissed off a vocal minority with the Google Reader shutdown, so any announcement is being met with pessimism and mistrust. 1: http://en.wikipedia.org/wiki/Self-fulfilling_prophecy http://en.wikipedia.org/wiki/Self-fulfilling_prophecy
- polskibus 14y ago
  No expiration date is just an evil omission. The risk is of obsolescence is there, whether they state the date or not. Making the risk visible to everyone makes the situation clearer for everyone. All that is needed is a table like http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173 http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173

clarle 14y ago

This is pretty awesome. It seems like the models are similar to the operational transformation models that they've been using in Wave/Docs (with the batched client operation submissions). It's definitely much more advanced than what Meteor does, which is just last-writer-wins. Still, I'm a bit wary that they're offering this as a API, rather than a framework. I don't know if I would build an application completely on top of an external API...

boucher 14y ago
Given that it seems to require building everything on the three collaborative primitives, and that much of Wave and the ideas behind operation transformations are open, it seems plausible that someone could build an open source implementation of the server component that the JavaScript library could then hook into.
- josephg 14y ago
  I'm the developer of ShareJS (sharejs.org) - and we have realtime JSON editing too. The technology is compatible, and it should be pretty easy to make ShareJS compatible with the GDrive client API.

sylvainstudiogd 14y ago

They should fix Google drive before launching an api... I don't understand why google didn't fix it yet. It's a big issue, bigger than the google reader thing... People use Google drive for their business (and some pay, like me), not google reader. WTF Google ! We are waiting so long !

jcomis 14y ago
Forgive my ignorance, but what is the problem you are referring to?
ChrisClark 14y ago
Fix what part of it? You're talking as if we all know what is wrong and needs to be fixed but I don't think we know what you are referring to. Google Drive works great for everyone I know, are you referring to the short downtime the other day?
- d--b 14y ago
  The sync is broken. It perpetually needs to be restarted on the desktop. Combine this with 2-steps authentication and you have to send yourself 3 messages per day to make this work.
- sylvainstudiogd 14y ago
  Sorry yes I assumed everybody knows because I know many people having problem around me... The famous unsyncable file, everybody I know including me have this issue. For some people Google drive use 100% of the cpu until it crashes, always, whatever they try. I got often disconnected for absolutly no reason. Well, I have collegueS that just can't make it work on their computers (recent iMac and macBook). And When I search on google, i find easily many people having the same problems, even today. I love Google product, but currently Google Drive is huge fail for me, I hope they fix it soon. They didn't update their app since a long time I think...
  - ChrisClark 14y ago
    I think that seems to be a common problem with Google. It could be only 1% of people are having the trouble you are having. But that could mean 10,000 people(not sure about real numbers) but at 1% it isn't on Google's priority list. :(

julien 14y ago

Wasn't Google killing Reader because they had to focus on less products? How many new products this week alone have they introduced? 3, 4, 5?

yanw 14y ago
No, they added 3,4,5 features to existing products, and it's fairly obvious that I'm not sure if you're trolling or not.
smogzer 14y ago
Google closing reader was probably something to do with the French un-digital papers that wanted the interwebs going to their website-o-pages to read content there.

resu_nimda 14y ago

This is slightly off-topic, but since everybody's commenting about it anyway: Was Google Reader (and Posterous, to a lesser extent) the tipping point for awareness and activism surrounding the shutdown of free services? This could be a big thing in 2013.

brianwillis 14y ago
The tipping point for me was Twitter's increasingly hostile approach to third party devs. I've been racking my brain trying to think of the first service that I used regularly that was shut down. Pownce maybe? (anyone else remember that?). I'm currently hunting for a replacement for Gmail that is self-hosted, or at least a solution where the cost of switching providers is low (i.e. I could shift my email to a new host without changing my email address or losing my message history). I'll probably end up using some sort of IMAP provider. There are a lot of features I'd stand to lose though. Conversation view is hugely useful, and Gmail's spam filter is just unbeatable.
- xcasex 14y ago
  pownce was indeed awesome. both twitter and in some part google have recently acted very hostile to the notion of the open web. (Although referring to corporations as a singular entity irks me somewhat)

anonfunction 14y ago

This is really a great API for developers and I can see a lot of different applications. Let's not let google reader's closing negate all the tools google provides for free.

pak 14y ago

Assuming I trust Google with all the data and all my users have Google Drive, this looks like a super easy way to make documents created in a web app editable in real time by multiple users. I'm curious about the details though, which would be ironed out with some more detailed playground examples. Does the API handle merging of the update events on the client side, or do I have to do all that work myself from the stream of insert/removal events? Can I handle them myself if I want? Assuming I want to extend the UI of these updatable strings, so that people can see other people's cursors and such, what would I need to do? Is the client-side library extendable so it can update my UI without hammering my customizations (cursor position, formatting, embedded data transformed into HTML)? How will that scale once the document grows to a considerable size (will I be able to update only changed portions of the DOM created by a large document without doing my own complex diffing logic on the client side)? For example, build me a basic rich text editor in this that mimicks some of the features of Docs, and show me how much extra code that takes. This code sample by itself doesn't make me confident that the above features would be simple: https://github.com/googledrive/realtime-playground/blob/master/js/rtpg.string.js https://github.com/googledrive/realtime-playground/blob/mast... It's precisely those richer features of the Google Docs experience that people crave when they say they want to add "realtime collaboration" to an app, not just .val()'ing form fields to the latest known value from the server. Right now this looks like it has the features of a backbone.js + Couch adapter (e.g., http://janmonschke.com/projects/backbone-couchdb.html http://janmonschke.com/projects/backbone-couchdb.html) except Google sits on all my data.

sylvinus 14y ago

I really thought this was an API for the driverless cars! Slight disappointment after following the link of course :)

deleted 14y ago

[deleted]

vineet 14y ago

The API seems to require users (and not just developers) to have to authorize the app :-( This kinda limits you to Google Docs style apps, as opposed to other crazy ideas I might have. I would also like to have an option to pay so that I can keep our users data private. Edit: Added clarification.

poundy 14y ago
Is there a way let users collaborate without authorizing the app? Developers authorize and create API with Google but it will be nice to allow users to collaborate anonymously like Sharing a Google Doc to the public.

msutherl 14y ago

Would it be possible, with this, to display files in your Google drive as read-only to people visiting a website? I'm thinking this would make a killer back-end for certain kinds of websites.

deleted 14y ago

[deleted]

chenster 14y ago

More importantly, how does Google ensure me it won't shut it down in 5 years?

rtexal 14y ago

Wondering if Google Keep (http://www.theverge.com/2013/3/17/4117780/google-keep-note-taking-app-spotted-in-drive-before-disappearing http://www.theverge.com/2013/3/17/4117780/google-keep-note-t...) is built on top this API ;) The API realtime capabilities will definitely drive interesting projects if Google Keep is just the start!

anonfunction 14y ago

Anyone have a good source for a list of all the official and unofficial google APIs? A quick search provided this but it does not have any of the unofficial internal API's that we love so much. https://developers.google.com/apis-explorer/ https://developers.google.com/apis-explorer/