Last week’s launch of Google Drive, a cloud-based platform offering 5GB of free storage, may have been big news, but perhaps bigger was the simultaneous launch of an associated Drive API and several Drive-enabled apps in the Chrome Web Store. The move implies that Drive is not just another Google product, but a step toward creating a larger ecosystem of online apps backed by Google services.
Rumors about “GDrive” have been circulating for the last six years, but after competitors like Dropbox, Box.net, and Microsoft’s SkyDrive had already pioneered cloud storage, Google Drive’s big reveal could have seemed a little anticlimactic. Perhaps anticipating this, Google partnered with several “launch partners” (including Portland-based collaboration startup Revisu) to showcase apps which demonstrate the utility of the Drive API.
The catch, for now, is that only web apps can use the Google Drive API, and those apps must be installed from the Chrome Web Store. (Google does offer a Drive Android app, and says they’re “working hard” on an iOS app.) The Drive API documentation notes that “[a]uthorization alone is not sufficient to give your app access to users’ files — app installation is also required. Apps will not have any API access to files unless users have first installed the app in Chrome Web Store.” However, this doesn’t limit users to the Chrome browser; it’s simply a means to authenticate users and authorize access.
Another caveat for developers is that Drive apps will only be able to access files which were created or opened by that app. The latter may seem like a catch-22–how do you open a new file, if you can only open files you’ve already opened?–but it just means that the Drive API is still pretty bare-bones, and depends on specific file IDs for access. To get a list of a user’s existing Drive files, you’ll have to go through the main Drive UI, the Google Picker API, or the Google Documents List API. It’s likely that the Drive API will expand to offer more functionality in the future.
UPDATE (May 4th, 2012): Google Developer Advocate Steven Bazyl offers clarification on the above issue:
The new Drive API intentionally has a more restrictive security model to protect users’ data. Rather than grant access to all documents when the user authorizes with OAuth, we added an additional layer of security which requires the user to explicitly decide which files to share. This is done by opening files with the app through the Drive UI (either drive.google.com or the embedded picker widget.) Authorized apps can also create new files by themselves. In this case, the overall OAuth permission is sufficient. Any files that the app creates can, of course, be re-opened by that app directly, assuming the user hasn’t revoked the app’s permission/uninstalled it. There is also a lower-level API, the older Documents List API, that also works on files in Drive. We’re encouraging apps to move to the more restrictive model whenever possible, but broader access is available for those apps that truly need it. We might add some middle-ground options (e.g. folder-level access) later on as we get feedback on the new API & security model from developers.
(Hat tip: Ars Technica)