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.
Maybe this is because they rushed it out the door as some people speculated, but it’s not a bad strategy to roll out a new API or SDK in a limited fashion focusing on the most compelling use case you want to drive usage of first. You can always add more features and use cases later. Harder to take away bad ones once they’re out.
I tried getting the ASP.NET MVC example up and running today but sadly it was incomplete (handling the OAuth2 callback wasn’t built in) so I didn’t get through it unfortunately. The idea that any web app can register as an editor for a file type differentiates Google Drive from the current competition. It will be interesting to see what kind of traction it gets.
The fight for the file system of the internet is definitely heating up. Dropbox has better clients and a much simpler API (that you can use for more things) but Google pushed the needle forward today in a big way.
