Hi everyone and welcome to today's Google Developers Live
for Google Drive.
Today I'm going to relive a little bit of my former life
before I was working on Drive and talk a little bit about
the Google Apps Marketplace.
There's a lot of developers who have been in the Google
Apps Marketplace for the past couple of years and who have
been integrating with Google Docs using the
Documents List API.
And lately just been getting a lot of questions from those
developers on how they can take those applications and
start leveraging some of the new features in the
Google Drive API.
And it actually turns out it's pretty easy to get started.
There are some limitations, a couple different options, and
how you can do it.
So I'm going to go over just two or three different
approaches and show how they work, what the pros and cons
of the different approaches are, and where you start
running into limitations.
So anyway, for those who are not familiar with the Google
Apps Marketplace, it's an enterprise storefront really
designed for small businesses.
But it's where developers can register their applications.
And domain administrators for Google Apps can go and install
those applications for all of the users on their domain.
It's been around for a few years.
Some really great applications in there and more still keep
coming on every day.
But when it was written, it was actually done pre-Drive.
It was actually when Drive was still referred to as Google
Docs and documentation and everything is still really
geared towards the older API, some of the older
authentication mechanisms like OAuth1 instead of
OAuth2 and so on.
It creates a little bit of confusion about how you can
use some of the newer APIs that Google is doing with the
enterprise storefront.
So I want to go into our developer console for the
marketplace here.
I already created this app a while back.
It's called GDL Test.
And I'll just go in and edit this listing.
Actually, you're already created here for using the
Google Doc List API.
So I actually have the scope reference here.
It might be a little hard to see.
I'll make it a little bit bigger if I can.
So you see the scope ref doc list.
And this is just the old Google Docs feed.
And here in my test domain, I have this Apps Rocks domain.
And I have this app already installed.
I have a really simple test application here.
It's just a little bit of a command line application using
the Ruby client.
What this has in here is just our Client ID and Secret.
We're using two-legged OAuth1.
And I'm just going to do a request for the Documents List
API impersonating a user using XOAuth Requestor ID.
And then print out the results.
And life is good.
So we see the results.
Not really worried about formatting any of this.
It's really just to see, are we getting back a valid
response or not?
So basically all that we just showed is that Marketplace
apps work with the Documents List API.
That's something that we already knew.
So what happens when we switch over and instead of using the
Documents List API, we actually just go
and use Drive API?
And in this case what we actually get back is a result.
It wasn't actually a result I expected.
Let me go and do one other thing.
Actually, no.
That is correct.
Basically what the point is, is it actually just works.
And the reason this works is really for one simple reason,
which is the Documents Lists scope is actually respected by
the Drive API.
And it's treated as equivalent to the full Drive scope.
There are a couple catches.
A couple things I want to point out in how I actually
set this up here.
So one is, I want to go back to our Google Apps
Marketplace.
Go to our vendor profile.
And there's a couple things you can see here.
In our console for the Marketplace, there's a link
underneath each application, which says, register for
additional APIs.
What that will do--
let's close that other one--
is take us to a version of the Google API console that is
tied to our Marketplace app.
And what we can do is that for the Marketplace, we can then
go and turn on different services such
as the Drive API.
There's one other thing though that has to happen for this to
work reliably, which is the API key.
Normally, the API key is something you would only use
in the context of unauthenticated API requests.
So if you're using some of the APIs which aren't necessarily
tied to user data but still we need to be tied to an API
project, you would use the API key as a way to link any of
those API calls to your specific
instance of the console.
And this is used for quota enforcement, for reporting,
and various other features.
Normally, if you're using authenticated request, this is
automatically done for you by virtue of your OAuth
credentials.
So when you authenticate a user, you have a token.
That token is bound to your application.
And also, of course, bound to your API console projects so
we can track quota.
For the Marketplace, due to the way that the keys are
generated for your application, that binding
isn't really there.
What you need to do in the case of a Marketplace app-- in
addition to signing your request with your application
client key and Secret--
you also need to set the API key.
Most of the client libraries, this is pretty easy.
In the case of Ruby, for example, we just do this once
when we create the client.
So even though we're still doing an authenticator
request, we're still signing with our apps credential, we
still need this one additional bit of information to make
sure that we had that correct binding to our application.
The upshot of that is we do actually get reporting.
You can see here's a request we just made today.
We get quota enforcement.
It makes it a little bit easier for us if your
application uses a lot of API quota and you
need additional traffic.
You need additional QPS.
We can actually set those for your project.
If you don't do that, what ends up happening is you end
up falling into a generic bucket of quota, which then
makes it a little bit more unpredictable for your
application.
So that's really the easiest way that you can actually
start using the Drive API features.
One of the other things that people have tried--
I'm actually going to show you what happens.
I'm going to go and edit this listing.
And I have another scope in here.
I already put this in a little earlier.
But I put in a scope for the Drive, the
new Drive scope here.
So you see it's little bit different the new format.
googleapis.com/auth/drive.
It's a little bit different than the old Docs one.
And I'm going to go and change this reference here to Drive.
And it'll save that.
I want to show you what happens.
What ends up happening is a little bit of UI issue.
This will actually work.
So if I go back and try this, I'll actually
get back a 200 response.
So everything is fine.
So 200.
That's good.
But here what we lose--
instead of having that really nice human friendly text that
says, integrates with Google Docs, we
just get the raw scope.
And this is just mostly a bug on our side.
There is a feature request to update the Marketplace to have
all the latest scopes.
So while this will technically work, it loses some of the
features in terms of the presentation.
And it also means that-- let's make this a little smaller--
when you do things like searching the Marketplace,
there are some features here for where you could filter
application based on the type of integration.
Applications that are using the Drive scopes are not going
to show up correctly in this filter.
So while maybe your first instinct is to, well I'm just
going to end up using the Drive API, let's use the Drive
scope, you do miss out on a lot of the Marketplace
features in terms of the benefits for discoverability
of your application.
So really the trick to doing this is use the old Documents
Lists scope but use the new API so that you get the
simplicity of the API, the more efficient wire protocols,
and of course some of the new features that are coming out,
that we have in our early access program that we
announced about a week or two ago.
There's one other thing that comes up in part of this.
Those who have been building newer Drive applications are
probably familiar with what we have in the Chrome Web Store,
which is these applications.
And one feature we've been promoting is the ability for
applications to hook into the new UI for Drive, to be in the
Create menu, to be able to open files from the Explorer.
In fact, there was an announcement earlier today
about how that experience has changed to really help promote
third party applications, make that experience of connecting
apps much better.
And as part of this, we have two different ways that
applications can get installed into Drive.
One is via the Chrome Web Store.
And the other is via an OAuth scope.
So there's a scope, Drive.install, which does the
same thing that you would have if you installed via the
Chrome Web Store of having that app
appear in Google Drive.
So of course then the question is, well can you do this from
the Apps Marketplace?
So if, for example, we were to go into our app settings.
Here we have these different scopes, you
have a Drives scope.
If I were to add a Drive.install scope and then
include that into our app, the question is, would that
actually work?
And unfortunately the answer to that is, no it doesn't.
Due to the way that that scope is enforced and checked, it
only works when it's actually a grant to an individual user,
not when it's a domain-wide grant.
There are some things you can do as a hybrid model if you
are an application which is in the Google Apps Marketplace
and you really love those features of being able to do
these domain-wide might authorizations, but you still
want get that UI integration.
Just do a hybrid model.
So you can have the domain administrator
install your app.
That gives you data access for all the users on the domain.
But then as they become users of your application, just have
an upsell or some other promotion within the
application to say-- hey, not only can you use our app here,
but you can get all these really cool other features
like appearing in the Drive UI so you
can create docs directly.
Or open our application from within Drive.
Click here to install that extension.
Then you could either use the OAuth, the Drive.install scope
to connect that application.
Or point them to the Chrome Web Store instead.
So a couple different options for how you can do that.
Honestly, it's not nearly as polished as I
would like it to be.
There are things that we're looking at to make this
experience a lot better.
But a lot of interest in having those domain-wide
deployment features combined with some of the new things
have been happening in the Chrome Web Store are something
that we're looking at.
But it's just not available today.
But the good news is that, if you are in the Google Apps
Marketplace, and you have an existing Docs integration,
there's really no reason why you shouldn't start looking at
migrating to the new Drive API.
You can still leverage the two-legged OAuth and the
domain-wide grants that you have today.
You just need to do a little bit of work just to enable
that project, use the API key.
And then you can start using the Drive API and any of the
new features that are in there.
So that's really it.
It's something that, a lot of questions from developers but
turns out to be really simple to do.
And other than that, I think that's all for today.
If there's any questions, certainly feel free to ask on
the Google Drive Developers community, Stack Overflow, or
find me on Google+.
Just send me a note.
I'll be happy to help.
Other than that, stay tuned for next week's Google
Developers Live.
Great.
Thanks.