Google has launched an SDK for its new cloud storage service, but the APIs are …

Google launched its long-awaited cloud storage offering today. The service, which is called Google Drive, will compete with incumbent Dropbox and Microsoft’s Skydrive. Alongside the launch this morning, Google also announced the availability of an SDK that will allow third-party developers to integrate with the service.

The new Google Drive APIs provide programmatic access to the contents of a user’s storage account, but with a number of significant restrictions that limit the scope of how developers can presently use the service. The APIs are only available to Web applications, which the user must "install" into their Google Drive account through the Chrome Web Store.

Web applications that use the APIs can only access files that they created themselves or files that the user individually chose to open in the application. The latter has to be done through the Web-based Google Drive interface or an embeddable Web-based file picker supplied by Google Drive. This model isn’t conducive to supporting native third-party mobile integration and rules out many common usage scenarios that are supported by competing storage services.

Although the current Google Drive APIs are disappointing for mobile developers, they have much to offer Web developers. Google is taking an approach that positions the service as a file manager for the Web. The APIs provide hooks that make it possible for Web applications to expose their functionality through Google’s user interface on the Google Drive website.

This means, for example, that users can right-click a file on the Google Drive website and select a third-party Web application that they want to use to open that file. Google also provides an HTML-based Google Drive file selection dialog that developers can embed in their websites to integrate with the service. These capabilities suggest that the first iteration of the Google Drive API is tailored to advance the Chrome OS vision, where the Web is the platform.

There are 18 Web applications that support Google Drive today. These launch partners, which had early access to the APIs, include Sliderocket, Lulu, Balsamiq, and a number of other content-oriented Web services. You can see the full list in the relevant section of the Chrome Web Store. Users of other browsers need not fret: unlike the Chrome applications and extensions that are distributed through the Chrome Web Store, Google Drive applications can be installed without using Chrome. The "installation" can be done in any browser and is really little more than an authentication process that gives the specified Web application access to the user's Google Drive account.

The documentation available today doesn’t indicate whether the API will be expanded to support more flexible usage in the future, but it seems very likely. We also suspect that Android will eventually get a built-in framework for integrating with Google Drive, similar to what Apple offers for iCloud. It’s not clear, however, how long it will take.

Google's biggest competitor in its new endeavor will be DropBox. One of the key drivers of Dropbox’s popularity is the extensive ecosystem of third-party mobile applications that integrate with the service. The pervasiveness of Dropbox support in mobile software has a kind of network effect that has helped to keep it entrenched. This phenomenon is particularly evident on iOS, where Dropbox integration gave application developers a way to work around the platform’s lack of conventional filesystem access.

Many users who rely on Dropbox functionality in third-party software are going to be reluctant to migrate to competing products until Dropbox’s rivals have attracted similarly broad ecosystems. The Google Drive API doesn’t offer the requisite capabilities today, but Google is well-positioned to make its service competitive on that front. Despite the limitations, the fact that there are any APIs at all available on the first day suggests that Google recognizes the importance of building developer mindshare around its storage product.

Update: it appears as though the Google Docs document list APIs provide some level of programmatic access to Google Drive files. The documentation on the Google Drive developer site currently doesn't discuss that functionality at all, and says that apps "will not have any API access to files unless users have first installed the app in the Chrome Web Store." It's not clear yet if the Google Docs API is the path that Google is going to use for supporting arbitrary Google Drive access by desktop and mobile applications.

Could a desktop application support Google Drive on Chrome platforms? Once your user installs your application, authorization is handled through OAuth 2 and the API is a fairly standard REST API, both of which are available to native applications. It's less than perfect, but could you have users install your "web app" then share the necessary secrets with your desktop program?

PS. This move on Google's part is pretty upsetting. Locking Drive integration to Chrome will harm the open web and hurt adaption of Drive.

Could a desktop application support Google Drive on Chrome platforms? Once your user installs your application, authorization is handled through OAuth 2 and the API is a fairly standard REST API, both of which are available to native applications. It's less than perfect, but could you have users install your "web app" then share the necessary secrets with your desktop program?

PS. This move on Google's part is pretty upsetting. Locking Drive integration to Chrome will harm the open web and hurt adaption of Drive.

Could a desktop application support Google Drive on Chrome platforms? Once your user installs your application, authorization is handled through OAuth 2 and the API is a fairly standard REST API, both of which are available to native applications. It's less than perfect, but could you have users install your "web app" then share the necessary secrets with your desktop program?

PS. This move on Google's part is pretty upsetting. Locking Drive integration to Chrome will harm the open web and hurt adaption of Drive.

It plainly says in the article that the API is not limited to Chrome, it's an API. So no harm to the open web. If you're concerned about native apps, that's a different story, but isn't the "open web". I agree though that it would be both stupid and seemingly arbitrary to block native apps but not web ones once authentication is taken care of.

Read harder. All that says is that you're giving them a license to do things like display a picture back at you. Both skydrive and dropbox *have* to say the same thing. It says very clearly in the quote they have from google how the license is limited

Quote:

You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours

and what they don't quote from Microsoft and Dropbox's terms of use:

Quote:

We may need your permission to do things you ask us to do with your stuff, for example, hosting your files, or sharing them at your direction. This includes product features visible to you, for example, image thumbnails or document previews. It also includes design choices we make to technically administer our Services, for example, how we redundantly backup data to keep it safe. You give us the permissions we need to do those things solely to provide the Services. This permission also extends to trusted third parties we work with to provide the Services, for example Amazon, which provides our storage space (again, only to provide the Services).

Quote:

You understand that Microsoft may need, and you hereby grant Microsoft the right, to use, modify, adapt, reproduce, distribute, and display content posted on the service solely to the extent necessary to provide the service.

To display your content on a website (especially when you put it in a public folder), they have to have a license to it. That's how these things have to work. Thank the lawyers for the rest of it.

It should be painfully obvious to anyone that Google Drive (the service) is just Google Docs (the service) renamed. Then, it had extra features added (the ability to have third-party web-based apps be the default handler for certain file types) and an official sync client for computers and mobile devices.

So, yes, the Google Docs API should still work for ANY file stored in Google Drive in the same (full) manner that it has been able to so far.

Could a desktop application support Google Drive on Chrome platforms? Once your user installs your application, authorization is handled through OAuth 2 and the API is a fairly standard REST API, both of which are available to native applications. It's less than perfect, but could you have users install your "web app" then share the necessary secrets with your desktop program?

PS. This move on Google's part is pretty upsetting. Locking Drive integration to Chrome will harm the open web and hurt adaption of Drive.

It plainly says in the article that the API is not limited to Chrome, it's an API. So no harm to the open web. If you're concerned about native apps, that's a different story, but isn't the "open web". I agree though that it would be both stupid and seemingly arbitrary to block native apps but not web ones once authentication is taken care of.

Read harder. All that says is that you're giving them a license to do things like display a picture back at you. Both skydrive and dropbox *have* to say the same thing. It says very clearly in the quote they have from google how the license is limited

Quote:

You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours

and what they don't quote from Microsoft and Dropbox's terms of use:

Quote:

We may need your permission to do things you ask us to do with your stuff, for example, hosting your files, or sharing them at your direction. This includes product features visible to you, for example, image thumbnails or document previews. It also includes design choices we make to technically administer our Services, for example, how we redundantly backup data to keep it safe. You give us the permissions we need to do those things solely to provide the Services. This permission also extends to trusted third parties we work with to provide the Services, for example Amazon, which provides our storage space (again, only to provide the Services).

Quote:

You understand that Microsoft may need, and you hereby grant Microsoft the right, to use, modify, adapt, reproduce, distribute, and display content posted on the service solely to the extent necessary to provide the service.

To display your content on a website (especially when you put it in a public folder), they have to have a license to it. That's how these things have to work. Thank the lawyers for the rest of it.

If Drive integration is only available to Chrome Apps, then it is tied to the Chrome Web Store, and thus to Chrome. If Chrome is only needed for initial authentication, than the REST API can be used by native applications as well. I fail to see how a website without a CRX file (not an app) is any different than a desktop application in terms of the Drive API. I plan on testing all this out this weekend if I get the chance.