Google I/O 101: Q&A On Using Google APIs

ANTONIO FUENTES: Hi, my name is Antonio Fuentes, and I'm a
product manager at Google.
Part of my job is to make sure that developers have a great
experience building applications
that use Google APIs.
Last week, I posted a YouTube video on the best practices
for using Google APIs and getting started quickly.
Some of you had questions on the content of the video.
And I'm here to address some of those questions.

There's a question on what happens if credentials you
obtain in the dev console are leaked.
It says, "What do I do next?" Credentials leaking is a risk
that any developer can face.
Luckily, the Google APIs Console makes it easy to deal
with this risk.
If your credentials ever leak, or you suspect they leak, or
they have leaked, it's easy to rotate
them in the dev console.
You can create additional keys in the dev console and roll
them out to your client application, and then turn the
leak key off whenever you want without creating a new project
in the dev console.

The next question says, "How long do OAuth tokens last?
When do they expire?" This is a good question.
In the video, we went through the OAuth flow, and how to
obtain access tokens, and how to obtain refresh tokens.
An access token generally lasts for an hour.
You can use a refresh token to request an access token or an
additional access token at any time.
So keep that in mind.
The good news is that if you use the Google Client
Libraries, which we also introduced in the video,
they'll take care of all of that logic for you.
So they'll exchange refresh tokens for access tokens when
your access tokens are ready to expire.
So if you use the client libraries, you don't even have
to worry about this.
If you're coding on your own without using the client
libraries, you would have to refresh your
access every hour.

The next question states, "How do I know which APIs are
supported by the Discovery Service?" The best way to do
this is to actually make an API call to the Discovery
Service or to use the APIs Explorer.
The APIs Explorer is a tool that we also introduced in
last week's video.
It will show you all the APIs that are currently exposed
through the Discovery Service.
You'll notice that some of the APIs in there have different
methods and have different resources exposed by the API.
All of that information is
available in the APIs Explorer.

The next question states, "The only way to hide a link from a
user's goo.gl dashboard is to click on checkbox and press
'Hide.' Unfortunately, we can't hide links with the help
of the API.
Could you add some method like url.hide to the API?" We get
questions like this every once in a while.
This is a feature request to the URL Shortener API.
And in my view, it's a good feature request.
So my recommendation is to go to the URL Shortener API
documentation, which I can show you now on the screen.

You can join the discussion group for the URL Shortener
API and submit a feature request for that.

Now back to the questions.

The next question states, "Why do we need different types of
client IDs such as server, web, and Android?" This is
actually a really good question.
You noticed on last week's video that when we obtain
credentials in the Google APIs Console, the APIs console will
ask us which type of key we need.
And some of the types available are for server
applications, for web applications, or for installed
applications such as Android and iOS.
Behind the scenes, the OAuth flow works a little bit
different depending on the device that your
application runs on.
And this is why the dev console will ask you in
advance what type of application
you're dealing with.
This will ensure that your applications are checked in
the most appropriate way.
So do specify, when you're asking for credentials in the
dev console, which type of application
you're working with.

The next question states, "What happens if I send both
an API key and a client ID when I make an API call?"
You'll recall from the video that you can obtain two types
of credentials in the dev console.
One is API keys and the other one is client IDs.
And they are a little bit different.
API keys allow you to make API calls that don't fetch
end-user data.
For example, a call to the Translate API.
There's no user data involved in that transaction, so you
can use an API key.
For other types of calls that do involve fetching end-user
data, such as a call to the Google+ API, for example, to
fetch an end user's posts, you will require a client ID.
It is possible to make an API key and passing both a client
ID and an API key in the same call, as the person asking
this question has pointed out.
There's very few situations in which you want to do this.
And I'll show you some of those on the screen right now.
When you go to the Google APIs Console and you want to
request keys, you'll notice that the simple API keys are
available for server or browser.
When you create a simple API key, you can actually block
the IP addresses that are allowed when making API calls
from your application.
So you can say, only requests should be accepted from the
following IP addresses.
That is if you're dealing with a server key.
If you're dealing with a browser key, you can actually
block HTTP referers.

So API keys always allow you to block IP
addresses or HTTP referers.
If you're using calls that fetch end-user data, you need
a client ID, which we learned how to obtain
in last week's webinar.
A client ID doesn't allow you, by itself, to do that IP
blocking or those HTTP referer blocking.
And you can do that by adding an API key.
So when you send both an API key and a client ID in the
same call, you get the benefits of using OAuth 2.0
from the client ID plus the ability to do HTTP referer
blocking and IP blocking from an API key.

Back to our questions.

The next question states, "How are client IDs and API keys
different?" I just covered this, but I think it's worth
mentioning it again.
Client IDs are used when you're making API calls that
fetch end-user data and will allow you to build an
application that accesses the data from an end user without
requiring their password.
For example, a call to the Google+ API to fetch the posts
for the user who's logged in or a call to the calendar API
to fetch an end user's calendars or tasks.
Simple API keys are used when such API calls do not fetch
end-user data.
An example is the URL Shortener API.
You can make a call to the URL Shortener API without a user
ever being logged in.
Another example is the Translate API.
It works the same.
You can make a call to the Translate API to do a
straight-up translation without a user
being logged in.
That is the fundamental difference between a client ID
and an API key.

There's more questions coming.
Here's one that says, "Can I make anonymous
calls to Google APIs?
The talk seems to indicate that this is not possible.
Why?" You'll recall in our last week's webinar that I
mentioned that when you make API calls to Google, with very
few exceptions, you need to pass your credentials that
identify your application when making these API calls.
This is good for you, the developer of an application.
This is good for your users.
This is good for Google.
This is good for everyone.
In general, when you pass credentials, you're
identifying your application with Google, which will allow
you to manage quota more effectively.
It will allow you to manage your user more
effectively, as well.
For example, you can identify end users who are making
inappropriate use of your application and who are
consuming all of your quota.
Remember, when you make API calls, you have a
limited set of quota.
You don't want a few end users from consuming all of it.
When you pass credentials, this allows you to identify
both end users and the application that is making
those calls.
So it's a good practice--
and in many cases required by Google--
to pass those credentials.

The next question is, "Where do I learn the details about
the OAuth 2.0 protocol?" You'll recall in the webinar
that we did a very brief summary of OAuth 2.0.
And there are lots of details that can be
covered about OAuth 2.0.
It is not a simple protocol to understand.
And there's an abundance of materials on the web to learn
about OAuth 2.0.
Google has extensive OAuth 2.0 documentation.
I provided a link to that documentation in last week's
webinar, so I suggest you go and check it out.
There's also a talk on Google I/O, which will be available
on YouTube, that covers all the details about OAuth 2.0,
with examples on how to use it to build your applications,
and actually will walk you through sample code.
So that would be a very good resource to check out.
For the documentation--
if I can show you--

the Google developer site has a page on OAuth 2.0 that not
only will walk you through the protocol, but will also walk
you through all the scenarios that exist for OAuth 2.0, such
as using OAuth 2.0 for login, using OAuth 2.0 for web server
applications, for client-side applications or JavaScript, or
for installed applications that run on mobile devices or
other installed applications.
So this page walks you through the flow in every case.
I just need to remind you, as I did in last week's webinar,
that if you're using the client libraries for Google
APIs, that all the details for OAuth are handled for you.
But it's always good to know what's
happening behind the scenes.

Back to our questions.

The next question states, "Why aren't APIs such as YouTube or
Maps showing up in the APIs Explorer?" You'll recall from
last week's webinar that the APIs Explorer is a user
interface that will show you a directory style of Google APIs
and all the methods in them.
And that there's a number of APIs that show up there.
But as the person who asked this question noticed, there
are APIs that are missing from that list,
such as Maps or YouTube.
The APIs that you see in the APIs Explorer are the APIs
that work with Google's Discovery Service.
Google is working to add Discovery Service
for all of its APIs.
And we're making great progress.
So hopefully, there will come a day when all of Google's
APIs will show in this directory.
So today, the support is limited to the ones you see in
the APIs Explorer.

The next question states, "What if I do not want to use
a Google Client Library?
What am I missing?" You are not required to use a Google
Client Library when you're making an API call.
There's also the possibility that you're working with a
programming language that Google doesn't have a client
library for yet.
In both cases, if you're not using a Google Client Library,
you'll be missing on some important features that are
designed to make your life easier.
The most important one is support for OAuth.
There's client libraries for nine different programming
languages available for Google.
And all of them implement the OAuth steps for you.
If you recall from last week's webinar, the OAuth steps are a
series of exchanges of API calls to Google's OAuth
endpoints for access tokens or refresh tokens.
All of those details are handled for you in a secure
way by the Google Client Libraries.
Another thing that the Google Client Libraries do is that
they format and can access the resources available for an API
automatically.
So when you use the client library, you're literally
ready to call that API in seconds.
They are also considered more secure because the code has
been built using the best practices for
calling Google APIs.
So we strongly encourage you to use
Google Client Libraries.
And if there's a language that you need to use that we're
missing, let us know.
And that would conclude the questions that you have asked
about last week's webinar.
You can use this moderator to keep them coming.
And I thank you very much for submitting your questions.