YouTube Developers Live: API v3 Overview

MALE SPEAKER: Shanghai GDG is a very
interesting developer community.
FEMALE SPEAKER: I'm glad somebody
has asked this question.
MALE SPEAKER: This is where the magic happens.
FEMALE SPEAKER: This is primarily a question and
answer show, so if any of you out there
would like to ask questions.

JAREK WILKIEWICZ: Good morning, everyone.
This is Jarek Wilkiewicz, Google Developer Live.
We have in the studio Jeremy Walker.
JEREMY WALKER: Yes, hello.
JAREK WILKIEWICZ: How are you doing, Jeremy?
JEREMY WALKER: Pretty good.
How are you doing?
JAREK WILKIEWICZ: I'm doing good.
Trying to wake up this morning.
It's still a little early.
On the Hangout, we have Jeffrey Posnick joining us
live from New York City.
How's life in New York, Jeff?
JEFFREY POSNICK: [INAUDIBLE]
three hours late here, so I'm fully woken up and post-lunch
and ready to go.
JAREK WILKIEWICZ: All right, great.
And today JJ Behrens, our fearless host, decided to take
a step back and enjoy the view from the couch.
So you guys can't see him, but he's in the studio in person
with us laughing right now.
OK, so we have an exciting program for you today.
We'll be talking about a not so secret but not
released set of APIs.
We have discussed them briefly at Google I/O previously.
So if you were at Google I/O, you might have participated in
a code lab that Jeff and a couple of API developers have
run over there.
We'll be talking about YouTube API v3 as well as our new
Analytics API.
As we mentioned in previous episodes of this show, these
are right now in developer preview.
So if you would like to use them, you have to apply using
the developer console.
And some of you might actually get to use them.
We are still a little selective about the use cases
that we want to test out before we launch the APIs, but
hopefully, it's not going to be that much longer.
I know Jeremy is eagerly awaiting API v3 because I
think he thinks v2 is kind of old.
Is it?
JEREMY WALKER: Yeah.
Yeah, I've started playing around with v3, and I do like
it a bit more.
JAREK WILKIEWICZ: Cool.
And then I think what we should do now is just
transition over to Jeff, who is going to walk us through
the intricacies of v3, using client APIs, and getting the
most out of the Analytics API.
So over to you, Jeff.
JEFFREY POSNICK: Absolutely.
Thanks, guys.
Yeah, so it'll be interesting to see how this goes, because
I think we could probably spend a couple hours talking
about these new APIs.
And I don't know if anybody really wants to hear me talk
for a few hours.
So I'm going to try to touch on some of the highlights and
start by talking a bit about the background of these new
APIs and what makes them so different than what we've
offered before.
So first of all, in the case of YouTube Analytics, we
haven't really offered the same sort of API before.
We've added YouTube Insights API, which did provide ways of
getting data related to your YouTube account performance,
but that was a very limited API in that we only exported a
zip file that contains a bunch of comma-separated values
documents within it.
It's very hard to parse that information and to use it in a
meaningful way.
So what we're going to be rolling out when we release
the YouTube Analytics API is a real full-featured, RESTful
JSON API for retrieving all sorts of different types of
YouTube reports.
It's going to be similar in some senses to the existing
Google Analytics API.
Some of the report definitions look very similar.
So if you've used that before, or if you've written code
that's gone against it, some of that will also apply to the
Analytics API.
On the other hand, we have the v3 of the Data API.
And as the name implies, we've also had a v1 and a v2, so
this isn't something brand new in terms of the type of things
that if offers.
But we are going to be very happy to roll out some new
features that are only going to be part of the V3 API.
But the real way to think about it is that this is
rewriting APIs on a more solid foundation.
These APIs are all going to be built on top of Google's new
common API infrastructure.
You know, our previous infrastructure is referred to
pretty much as Google Data, or G Data.
And those APIs that were written against that were all
RESTful, but they used Atom XML as their native
interchange format.
And there were a certain set of client libraries that
weren't particularly well maintained that went against
those older APIs.
But because we're building on top of this new beautiful
infrastructure, we're going to be able to take advantage of
everything else that--
all the effort that Google is putting into their APIs across
all platforms.
So if you've used Google+'s APIs before, if you used
things like Google Latitudes, if you've used the new Google
Drive APIs, then you've already built on top of this
infrastructure, and you are already will be familiar with
a lot of things when you get started with
the new YouTube APIs.
And as I mentioned before, these are all RESTful APIs.
So if you are familiar with making URL requests and
getting back data, if you get that, this all should be very
similar to what you've done in the past, except JSON--
JavaScript Object Notation--
is the native format.
So you don't have to worry about parsing XML.
As far as I know, we're not even going to be offering any
sort of XML-based options.
It really is JSON all the way.
And I think a lot of people are going to
be happy about that.
We have a lot of folks who've previously used Version 2 of
the Data API and had to manually specify that they
wanted to get JSON back, but it wasn't the default.
And I think that this was the right choice moving forward in
terms of making it easier for folks to
interact with the APIs.
So I'm going to start this screen-sharing session now and
start showing off a few things related to new API
infrastructure.
And hopefully, this will be visible for everybody out
there who's watching after the fact.
But if it's not, we're going to share the links to all
these things I'm covering--
well, most of the public things I'm covering--
after the fact.
And we'll probably post that on our YouTube for Developers
Google+ page.
So the first thing I wanted to point out is we have this
really nice web page--
developers.google.com--
and this is the home for all our APIs now, including
YouTube APIs.
And one of the things on there is a list of all the client
libraries that we support with the new Google APIs
infrastructure.
So you'll see it's a pretty nice list.
There are nine officially supported client libraries for
various languages.
And I was actually poking around.
I saw that somebody is doing I guess an unofficial version of
these client libraries for PEARL, which maybe isn't as
relevant today as it was 10 years ago.
But it's still kind of cool that there are some folks--
even if it's not an official client library, there are some
folks who are taking it upon themselves to try to implement
something that works against our APIs.
But many of the major languages that everybody out
there is probably programming against are covered here.
I know that folks who are, for instance, Python programmers--
this just came up a little bit earlier today in a Google
group, people saying, hey, why isn't there Python client
library support for Version 2 of the API?
Python folks have been kind of left out in the dust for a
while, unfortunately, and I'm happy to say that we're going
to have full-featured rich support for Python developers
in Version 3 of the API.
One of the things that's actually nice about the way
the client libraries are set up, not just for the YouTube
API, but for anything built on top of the Google APIs
infrastructure, is that many of them dynamically generates
the classes that are necessary to interact with the relevant
APIs at run time rather than having to pre-compile the
classes ahead of time, and you have to make sure that your
library is always up to date and that we didn't release new
definitions of what the API will look like two weeks ago,
and you just never updated your local copy of the client
library to match that.
The ones that I know for sure that are doing this at run
time are JavaScript, Python, and Ruby.
And the way that works is that they will contact our servers.
We have this central definition document for--
I guess we're calling it a discovery
document for the API.
That just details all the methods and data types that
the API supports.
So when you run your code, the first thing it does is it'll
download that document.
It'll build up all the client
descriptions that are necessary.
And you never have to worry about your code being out of
date or not matching the API definition again.
So that's going to be a real benefit for folks who have
struggled in the past with client libraries that have
been out of date.
And like I said, that's not the case for
every single language.
I think for Java, for instance, we need to
pre-generate some of those classes.
But I think you'll see that we're a lot better about
getting fresh copies of those class definitions pushed out
when v3 is released.

One other thing to note about this new client library,
especially for the Java version, is that is fully
compatible with Android.
And this has been a bit of a pain point for developers who
have in the past tried to use Version 2 of the Data API on
the Android platform.
The existing G Data client library wasn't really a good
fit for an Android environment.
I think there might have been some folks who've found ways
to get the G Data client library to work.
But really, you have to end up just writing your own, making
your own HTTP calls and parsing adjacent data yourself
if you wanted to use a Version 2 of the API on Android.
So once Version 3 is available and once the Analytics API--
everything I say here also applies to Analytics API.
Once those are available, you'll be able to use the
official client library for Java, and there's going to be
plenty of examples out there of how you could do that on
the Android environments.

So that's a little bit about the infrastructure.
And one of the things that I feel bad about is that folks
can't really play around with the APIs themselves quite yet.
So as Jareck mentioned at the top, we're still in kind of a
closed beta, or in some cases alpha release of these APIs.
So I'm going to show you the steps that you will be able to
go through soon--
for some definition of soon-- to get started building
against the APIs.
And file this video away.
You can go back and look at it later.
There's actually some other good video resources out there
that explain these steps from the context of other APIs.
Not necessarily YouTube API, but a lot of these steps are
common regardless of what API you're using.
So I'll just walk you through that a little bit here.
So what I'm at right now is what we're calling our Google
APIs Console.
You can get through it by going to
code.google.com/apis/console.
And I have an existing project over here, and I'm going to
walk you through the steps of creating a new one.
So whenever you're building against a new Google APIs
platform, you need to first to register a project.
And this concept is different for folks who might be--
shoot, try a new one.
It's different for folks who might be used to just, for
instance, registering a developer key.
If you are a Version 2 developer, you probably are
familiar with the process of registering YouTube API
developer keys.
This API console replaces the need to do that.
And it's nice because it applies to all Google APIs, as
you're not just registering a YouTube API developer key.
You're registering one project identity that's common
throughout all the APIs you're using.
So if you're using the YouTube API, and the YouTube Analytics
API, and maybe the Google Analytics API, and maybe the
Google Drive API all within the same project, you have one
central place to manage all the things
specific to that project.
And that's the API Console.
Let's say GGL Test Project.
Just create that.
So the first step is creating a new project if you don't
already have one.
And you're then taken to this list of different APIs that
you could enable.
So before you could use any API, you just have to click on
Enable over here.
And we're over here going to see just a Request Access.
That's the link that folks are going to see if they are not
yet permissioned.
And I'm afraid most folks are going to be in that state
right now because I'm the one who controls the permission
things to some extent.
I was able to turn on YouTube Analytics API and YouTube Data
API for my specific project.
So sorry about that, but again, folks are not always
going to be in that boat.
But it is something that we are turning on for select
users right now.
Once it's fully available, you'll be able to just flip
the switch and enable that for your project.
And once you have the project set up, you can
do a number of things.
The relevant stuff that you want to think about is under
the API Access tab.
And this is where you get some of the identifiers that you're
going to need to use if you want to talk to either the
YouTube API or really any of the APIs that you've enabled
for your project.
So we have a concept of both authenticated and
unauthenticated requests against the YouTube API.
Unauthenticated requests are just requests made without the
credentials of any given user.
There are many types of requests that you can make
unauthenticated, such as search requests-- for
instance, searching for videos or getting the contents of a
given playlist things like that.
For those types of calls, you can look in the Simple API
Access section on this web page, and you can get your API
key directly from there.
So that is just a piece of identification.
That doesn't actually authenticate you or have any
authorization, but it just associates your API calls with
this given API Console project.
So it's slightly different for folks who are used to being
able to make completely anonymous calls against v2,
where you didn't even have to specify a developer key.
But it's not really that much of a burden to take that
particular key and use that in your application.
So that's where you get the unauthenticated API key from.
But all the interesting stuff nowadays happens with OAuth 2
and authenticator requests.
So this is also where you set up your OAuth 2 app for this.
For folks who are not familiar with OAuth 2 and maybe not
familiar with the rather interesting legacy that we
have of various older and currently deprecated forms of
authentication authorization that the YouTube API supported
at one time, OAuth 2 is what we're recommending everybody
use nowadays.
Even with our older APIs.
But it's the only form of authorization that's supported
with both the v3 API, Data API, and the
YouTube analytics API.
Everybody needs to use OAuth 2.
There's no more client login.
There's no more Auth sub.
And even OAuth 1 isn't something that we support.
So I will post some links to some great getting started
resources with regards to OAuth 2 on our YouTube for
Developers G+ page because it's a rather large topic.
I've given talks about it in the past where I've spent
about 40 minutes going over everything.
There's even a book about now written by one of our
colleagues at Google Developer Relations.
So there's lots of ways to get started about that, but the
important thing is that when you're setting up your OAuth 2
access, you need to generate things like a client ID, and
in some cases, a client secret.
You can get that information from here.
And I'm going to hand over regenerating all these key
values as soon as we're done since they're not particularly
secret anymore now that they're being broadcast out
there, which is actually nice.
So you can go and reset these things rather than having to
be stuck with your information being public.
So I'll show you a little bit later where these values end
up getting plugged in when you're writing real code that
talks to the new APIs.
But just keep in the back of your head--
the API Access tab and the API Console is where you go to
generate that information.
I can just show you right now what that interface looks like
where you generate a new client ID.
You choose whether your application is a web
application, an installed application, or a service
account, which is actually a fairly new concept that we
just recently rolled out.
For most YouTube API developers, I think it's going
to be either a web application, which is pretty
much anything that's run in a web browser, really, or an
installed application, which could be things that are
either command line scripts, or if you're writing code
that's being run on a specific type of console or device that
doesn't have a web browser, that would be another case
where you would use the installed
application for that.
So that's just how you create that.
So I showed you how you can create a project.
It's a little bit of a tease because you can't actually use
those APIs yet in your own project.
But where we can play around with those APIs is on this
web-based interface to old Google APIs.
So we call it the APIs Explorer.
And you get there by going to developers.googl
e.com/apis-explorer.
And I think that's all you need to go to, yeah.
And you'll get to see a full list of APIs that we have.
And for our purposes, we could play around with either the
YouTube Analytics API or the YouTube API
directly in a browser.
So again, this won't let you write your own code that will
interact with the APIs.
But it will let you make sample calls against the APIs
and get the results back in a web browser.
And you can do this yourself.
You don't have to be permissioned ahead of time.
One of the nice things is that it will also take care of
doing OAuth 2 for us.
So flipping the switch over here--
authorize request using OAuth 2.
I'm going to just click that, and I'm
going to click Authorize.
And now I've gone through the OAuth 2 flow, basically.
Because I was already logged in to my Google account, I
didn't have to type in my username and password again.
So it was just the authorization stuff.
But now I've authorized the Google APIs Explorer to make
requests on my behalf.
And let's try some here.
So first of all, you could do some universal search.

This is truly universal search.
If you were previously doing searches against the Version 2
API, you might know that you only got
back videos by default.
There were ways of doing channel searches and playlist
searches, but they would be at different points.
So you couldn't really just do one search that would return
the most relevant videos and channels and play lists.
In Version 3, you can.
So let's try it out to start with.
So let's put in YouTube API.
That'll be our search string.
There's a couple of other fields that you could fill out
if you want to, but we'll just leave them as default for now.
And let's click Execute.
And we get an error.
So this is one of the reasons why we don't have things
opened up to everybody right yet.
There are people doing active development pretty much as we
speak on the API.
And I had heard there was an issue this morning with doing
unauthorized requests for searches, just due to some
random bug.
And I thought that an authorized request would work,
but as it turns out, it doesn't.
So play around with this maybe tomorrow or
in a couple of days.
That's specific to this search list, though.
But there are a few other things that should work, such
as doing a channels list.
So I'm in this case going to try to retrieve this.
This is the typical one that you make to get a list of your
YouTube channel, basically.
So you can see this is doing a request against
googleapis.com/y outube/v3alpha/channels.

I'm saying that this is mine.
And here's a key, or API key.
The Google APIs Explorer automatically fills
in the key for you.
So you don't have to register your own key, as we talked
about before.
So don't worry about that part.
So you'll see the response.
This is a very basic response.
It shows me that I have this identifier for my channel.
And pretty much just saying this is the ID.
It happens to be a channel.
And that's something that is due to the fact that I've only
specified ID as the part that I want when I get a response
back from the API.
So this is actually a very important concept that's
probably going to take developers some time to get
used to when they start working with v3 API.
If you've done any development against the v2 API, you know
that by default we give you everything.
If you request a video entry, for instance or if you request
your YouTube channel entry, you'll get every piece of
metadata that is within the API by default.
And it is possible to filter out some of that metadata.
And a lot of people do that because they don't need to get
a couple of kilobytes maybe or several hundred bytes worth of
data back when all they care about is a
channel ID, for instance.
So in order to save speed, save--
sorry--
transmission time, and just optimize things, they'll say--
[SNEEZE]
JEFFREY POSNICK: Bless you.
They'll say, hey, I'll use the filter parameter and say that
I only want the ID back.
So that was how things are done in v2.
We've kind of rethought things in v3, and we've said, OK,
well, instead of people having to specifically tell us what
they don't want and by default giving them everything, how
about we make people specifically say that they do
want certain parts of the response.
And if they don't ask for it, we don't give it to them.
So this does mean that there's a little bit of work that
needs to be done on your part in order--
no pun intended--
in order to determine which parts you want
to get back in response.
But once you do that, you'll realize that hey, you're
getting back a lot more optimized responses
than you used to.
So if I put ID, which is a very basic part, I will only
get back this identifier over here for my channel.
I could also put in the content details.
That's another relevant one.
And these are all in our documentation right now.
So I'm trying to remember a few relevant ones, but I can
actually just pop over to the dots and take a look.
But it's just adding in that content details, though.
That created an extra subsection
within the JSON response.
It has all the content details.
And in this case, it has the identifier of my uploads list,
and the fact that this is a public list of videos.
So let me just pull up our docs real quick.
See the big Experimental next to Version 3.
And I'm going to be doing a channels list.
So I'm going to go to Reference, Channels, List.
And I'm going to look over here.
It says Parts.
And you can see a definition of types of
supported values for parts.
So we have ID, Content Details, Snippet, and
Statistics.
So let me actually include all that and just show you the
full response I could get back.

And just comma separate a string.

Click Execute.
So you see a bunch more data.
And this should be more familiar for folks who have
done v2 type responses, and they're used to getting back
things like the number of views for all the videos in
your channel.
The total number of public videos, your subscribers, a
thumbnail for my account and its title
and things like that.
One of the interesting things is the part that
was entitled Snippet.
Most of our API endpoints do support the snippet part.
And this is kind of a shorthand that we've come up
with to say that you want to get back the most relevant
information in a response that would be useful when
displaying that response visually somewhere.
So the type of things that you need when displaying something
visually are usually a title, description,
some sort of thumbnail.
That's usually enough in order to give you a very basic
visual representation of something.
So that's the type of things you get back in Snippet.
You get back the title.
You get back a thumbnail.
My channel doesn't happen to have a description so there's
nothing there.
But you'll see the same sort of thing if we, for instance,
do a video query.
So let's just pick a video ID real quick.
And I'll just grab one from our Player API demo page.
That's always a good place to go to get a video ID.

So we have that ID.
And we're just going to go back over here to Videos List,
look for an ID.
That, or you put in Parts, Snippet.

We'll do an Execute, and here w get back something very
similar to the folks who are familiar with Version 2.
You have title description.
Tags are useful.
You have this back in the snippet.
You have video category in various thumbnails.

I know this is a little bit specific to folks who have
written code, especially doing JavaScript parsing of Version
2 responses.
But you'll know that it's very difficult, for instance, to
figure out what the high-quality thumbnail is for
when you're parsing the v2 response.
You kind of have to iterate through all the items and
check one of the JSON attributes.
And it's quite annoying.
So one of the nice things that we've done is we've made it so
you can just do Thumbnails, and then do a few things that
has the property value high within that, and then get the
property of the URL.
And it makes things a little bit easier.
So we've tried to make those types of little changes
through the API.

So those are a few examples.
And try a little bit more on your own.
I'm not going to show off the Analytics API right this
second, meaning I don't have very useful
information in my accounts.
But you could do the same sort of requests over here.
It's a little trickier to format the proper values for
the IDs field, for instance, which needs to be set to
content to channel equals the channel identifier string,
which is something distinct from your username.
You're going to have to spend a little time looking through
the Docs if you want to get started on this
completely on your own.
Otherwise, you can wait until we release some sample code.
That makes it a little easier for folks to
use these new APIs.
But I just wanted to throw the fact that people can play
around with Analytics API now, too.

So one thing that I just want to go back for a second and
talk about, because it's another thing that's important
when thinking about the API, is the fact that--
let me put in Content, Details, and no.

Edit Picture.

All right.
There we go.
So you'll notice that we have returned to the uploads this
uu, and then a pretty long string of characters
identifiers.
This is our way of moving towards a universal name space
for different types of video lists and making it possible
to retrieve any type of list of videos using a single API
method, regardless of whether it's a list of videos that
somebody has uploaded, or it's a list of videos
somebody has favorited.
Or it's a list of videos that belong in a given play list.
Or if it's a list of videos that a user has Liked in the
past, which is something new that we're going
to be rolling out.
All those things correspond to specific list identifiers that
have different prefixes.
So uu is the prefix being used for the uploads
feed, more or less.
And pl, many people have seen the pl prefix used on list
identifiers on the website in the past.
So the same pl identifiers can now be passed directly into
Methods in the API.
So I just copied that.
I'm going to show you how that's done.
If you do play list items list.
I'm going to put in Snippet ID.
And I'm going to put in the ID of my group section.
And I'm going to put in the ID of my uploads list and then
click Execute.
This should work.
And this will show me all the videos that are
uploaded in my account.
So again, this would have worked equally well if I had
put in a PL ID over here, if I had an actual playlist ID.
So we're treating lists of videos as if they were just
lists of videos, regardless of what their origin is.
And that should make things easier from your end in terms
of implementing code.
So just one other thing I wanted to point out.

So I've showed you a bunch of demos that are done in the web
interface now.
I've talked about the API Console.
I did want to show some very preliminary Python code, in
this case, where we're doing some of the same things we've
done before via the web interface.
So in this particular case, I'm going to show you a Python
example that's used within Google APIs Python library
that will make an authenticator request to
Channels List to get the uploads list identifier, the
same identifier we were just talking about previously.
And then it will take that identifier and make a playlist
items list call to get all the videos in my uploads feed.
So it's pretty much exactly what we just saw in the web
interface, except some Python code to do that.
So before I run through the code, let me show you what it
actually looks like because I always like doing that first.
So I can run my uploads.py.

And you'll notice that it immediately will take me to
this page where I can quick Allow Access, and complete the
OAuth 2 flow.
So this is [INAUDIBLE], and you'll see the list of all the
videos in my account, including a bunch of videos
from my site.
So this is possible because we are using Google APIs Python
client library, and that has a really good support for OAuth
that's already built into it.
So we don't have to worry about the details of actually
handling the redirects, for instance, or even persisting
the credentials after we've authorized for the first time.
The client library will take care of all that for us, and
I'll show you how--
excuse me--
from looking at the code.

And one other thing to note is that the second we run it, I
don't have to go through the OAuth 2 authorization again.
It'll persist those tokens for us and it'll reduce them.
So while it might seem a little bit weird, hey, why do
I have to open up a web browser when I have a command
line installed application?
Yeah, that's not ideal for automated processes, but you
only have to do it once.
And as long as you don't revoke your OAuth 2
credentials, you can reuse those cached credentials
pretty much indefinitely.
So in that respect, you don't have to store your username or
password anywhere on the local file system.
You're storing these opaque credentials in a file that
only your user has access to.
So it really is a win from a security perspective, and it's
really, really not that much harder than doing something
like client login with a username and password.

I can't talk about all the details of how the Python
client library handles things.
There's a lot of magic that's going on.
And Jared Gregorio, who's on our team and wrote this, did a
wonderful job of that.
And he's made it so that you have to just put in a couple
lines of code and it'll take care, of instance, the OAuth 2
flow for you
So this literally is all you need to do to do OAuth 2 from
within your Python application.
You have to initialize this flow object.
And you're saying you're loading the flow from a client
secrets file.
A client secrets file is a JSON-formatted file that
contains the client ID, and the client's secret, and the
redirect scopes, and few other things that came from the API
Console in a previous call.
So you just store that somewhere locally.
There's some spec for how you create that
client secrets file.
I don't want to go into it right now, but there's spec
for how to do that link-to from the
Python client library.
And we always said that we wanted to do the
scope off the YouTube.
And we're saying the next line, that we want to use this
particular file for storage.
So just hold on one second.

You can hear some pings in the background--
I'm sorry.

So we're saying that we want to use this particular file
for storage.
And I'm sorry--
Jareck or Jeremy, interrupt me if there's something I should
be doing there.
JAREK WILKIEWICZ: I think we are mesmerized
by your code, Jeff.
JEFFREY POSNICK: Pardon?
JAREK WILKIEWICZ: We are mesmerized by your code, so
we're in a trance right now, salivating
over that Python code.
JEFFREY POSNICK: You know what?
I am always embarrassed showing off my Python code in
front of JJ, in particular, because he's
a true Python guru.
So JJ, mercifully, is not on the camera today.
Otherwise he'd probably be talking about my indentation,
for instance, which is the worst thing you could get
reprimanded for if you're a Python programmer.
In any case, though, we have the definition of where the
local file is for storing your credentials.
And we try to reuse the credentials over here.
So we see if the credentials are valid.
If they are, we'll reuse them.
If they're not, then we'll just go through the whole
flow, which opens up the web browser for us automatically.
It'll actually run local web server for us.
So the web browser will end up redirecting to
a local host URL.
And that Python lone server that's running will listen for
the response.
And once it gets the response, it'll complete the OAuth 2
flow for us without us really having intervene at all.
So it's super nifty.
And at that point, we create this YouTube object.
And over here, we are doing what I mentioned before, where
it generates the client bindings on the
fly, more or less.
So what we do is we call the build method, and we say I'm
using the YouTube service in the v3 alpha version, and it's
going to go and download the discovery document for us.
And it's going to build all the necessary bindings that we
need without us having to have that precompiled or stored
anywhere ahead of time.
So it's always going to be fresh.
And at this point, we're doing a channels list call on that
YouTube object, specifying the same sort of frameworks we saw
in the web UI.
And we're going to then iterate over the response.
So we get back a list of channels.
We iterate over that.
And I only have one channel, which most
people certainly would.
And it's the content details upload list ID that we want to
grab over here.
And we're then going to pass that to this
youtube.playlistitems.list call.
Very similar, again, to the web interface.
This playlistid.list_id and the part is Snippet, and we
can then iterate our other response.
So again, this is all JSON data that you get back, and it
gets deserialized into Python objects that you can then
interact with.
So we're grabbing the title, and we're
grabbing the video ID.
And I end up printing that out in a user interface.
We can write that.
So that's a really simple example.
We're going to release some examples for doing Analytics
reports in the near future.
We're going to list--
I would show you the Search example right now, but the
search service isn't currently working the way it should, so
it wouldn't be a good demo.
And we're going to be trying to get out as much sample code
as we can as soon as we can, perhaps even before the public
release of the both v3 and the Analytics API.
Because we know that sample code is really what a lot of
developers go on when they're getting started with any sort
of new API.
So if you don't hear too much from me in the Google
Developer forums, it's because I'm head down writing sample
code for everybody.

And I think that's pretty much what I wanted to show for now.
I've used a nice chunk of time.
As I mentioned, I probably could end up using a lot.
more.
So if you ever see me on the street in New York City, feel
free to corner me and ask me about
any sort of API questions.
I get that so much, paparazzi just following me around and
wanting to get early access to v3 or wanting to know random
things about v2.
So feel free to do so.
JAREK WILKIEWICZ: Actually, I think JJ, if he were live, he
would have said that you actually predict what
questions people are likely to ask, then you follow them and
answer before they have a chance to ask them.
Is that right, JJ?
JJ BEHRENS: That's right.
JAREK WILKIEWICZ: All right.
JJ is nodding his head.
JEFFREY POSNICK: Well, that's using the Google Prediction
API, which is one of the APIs we didn't cover.
But yeah, add the Google Prediction API to your own
code, and you can do the same.
JAREK WILKIEWICZ: So you're training the algorithm while
people ask you questions?
JEFFREY POSNICK: Yes, that's right.
JAREK WILKIEWICZ: Ah, this is your secret.
All right.
So we have a few questions.
There were actually questions on the live stream in the
comments section as well as in the Moderator.
So let's take a few.
So let's start with the Moderator.
The top-ranked question is about obtaining video
thumbnails that look like a storyboard.
So there's a question whether our existing Version 2 API
provides that in the API responses.
And I think the answer is not this moment, right, Jeff?
JEFFREY POSNICK: Yeah.
So we do expose three different thumbnails from
those videos that are tagged with, I think,
start, middle, and end.
That is different than what I think the person is asking
about, which is they've noticed that the YouTube
player for a lot of videos--
I don't know what percentage of videos nowadays,
but a lot of them--
lets you move over the scrub bar with your mouse.
And you see a thumbnail of that given point in the video.
So that's something new that we've started doing.
We're not exposing that level of thumbnail data via the API.
I kind of doubt that we ever will.
I'm not going to say that for sure, but I'm not aware of any
plans for us to do anything more than the beginning,
middle, and end.
JAREK WILKIEWICZ: Cool.
Thanks, Jeff.
Again, if this is something that is important and you guys
feel like we should, then please file that in our issue
tracker on the public side--
it's linked from youtube.com/dev--
and we will push on your behalf to see if
we can make it happen.
But as Jeff mentioned, right now no plans.
Next question is about retrieving
multiple parts of a response.
So as Jeff mentioned, there's a convenient way to obtain,
for example, snippets that will give you a set of data
elements relevant for display.
Now, what does response look like if you
actually ask for more?
Can you do that, first, and then what does it look like?
JEFFREY POSNICK: Yeah, you definitely can.
So I'll just pull that up again via screenshare.
That would be the easiest way to do that.
Let me try to share just the window this time.
So if you go to the Google APIs Explorer.
And I guess the most relevant way to do it is for the
example where we do the videos list.
So let me just pull up that video ID.
So prat is just a comma-separated list of parts.
And if you specify multiple ones, it'll be the union of
all those parts.

And if I go over here, Reference and take Videos
List, and then take a look over here.
Actually, one thing to note is that instead of just going to
the APIs Explorer, we do have an embedded version of the
APIs Explorer that is tied to the specific service that
you're looking at in the Docs.
So right now I'm looking at Videos List.
And if you go over here, you'll see pretty much the
same user interface.
It's really just a tiny subset of it, but it's already on the
user's list method.
So I can just put it over here equally well.
So let me do that instead.
So let's just get the list of parts.
Copy that over here.
Whole bunch of different parts, like for this.
I'm pretty sure--
well, let's actually try to see if we have spaces in there
whether it likes it.
OK, so it's happy enough even with spaces.
So this just shows you-- and here if I take a look at
minimizing some things, which is a nice thing to do, you'll
see you have this parent element, parent container
element, whose value is actually the same as the ID.
So this makes is easy if you're looking at multiple
video IDs at once, for instance, you can specify
three or four or whatever video IDs, you'll know what
part of the response corresponds to the specific
video you're interested in just by using
that ID as a key.
So in this case, we're only looking at one.
But within here you'll see there's a snippet item.
There's a constant details,
statistics, status, and player.
And those each have their own subsections with
information within it.
So you can definitely specify as many as you like, or as few
as you like.
If you only want to know what the view count is for a given
video, then all you need to do is put down statistics and
forget all that other information
that you don't want.
JAREK WILKIEWICZ: Cool.
Great.
Thanks, Jeff.
There is one more comment in the Moderator.
It's in English and in Mandarin, I suppose.
It's Like.
So my response to that is thank you very much.
And I'm not really that good with Mandarin, but I will
answer in Polish.
[SPEAKING POLISH].
But let's transition to a couple of the questions that I
saw popping up in the live feed in the comments.
So one question was about YouTube iOS as far the API is
concerned, is there a new YouTube iOS API?
And I think, Jeff, you were talking about the different
client libraries.
So I think the question really is, what about the iOS?
Is the v3 actually helping developers in any way?

JEFFREY POSNICK: There definitely is a client library
for Objective-C that will be available for use in both
version three of the API and the YouTube Analytics API.

It will help developers, but it's actually, interesting for
Objective-C because we didn't really have quite the same
problem with the Objective-C client library in v2 as we did
with maybe Java, for instance, or Python, where either the
bindings were pretty out of date or there was no really
good support for OAuth 2.
That really hasn't been the case with Objective-C. We have
a fantastic maintainer of the Objective-C library, Greg
Robbins, who's been really good about adding
new things to it.
So it's not like you're in very bad shape if you wanted
to use the Objective-C client library with v2.
That being said, it'll strictly be a better
experience I think I could say with some degree of certainty
if you're doing v3 programming using the
Objective-C client library.
And you know, it's definitely something
that should be supported.
JAREK WILKIEWICZ: Great.
And eight other languages, right?
JEFFREY POSNICK: And eight other languages, yes.
JAREK WILKIEWICZ: Sounds good.
Couple of final questions since we
have a few more minutes.
So there was one question about embedding videos on one
side from a YouTube channel.
So if someone has a bunch of videos uploaded, how can they
easily embed them on the channel?
And then can they actually decide how
the videos are presented?
There was a specific question about determining the order by
sorting based on tag values or maybe any part of metadata.
Any hints of how that can be done?
What are the possibilities there?
JEFFREY POSNICK: OK.
So I want to make sure I fully understand the question.
I'm not sure you're the person to clarify it or not.
So let me answer the assumption that the person has
a list of videos, either already in a playlist or
already in their account or maybe just a list of arbitrary
video IDs, and their goal is to display them in an
intelligent fashion on a web page in some sort of player.
Does that kind of sound like what--
JAREK WILKIEWICZ: Sure.
That's the general case.
I think the uploads case was another one, the simple case.
So maybe we could cover both.
JEFFREY POSNICK: Sure.
So what you would want to do in that particular case is use
our standard embedded player but make use of its list
playback capabilities.
So we talked about that a little bit in a blog post.
And here, since I'm in the screen-sharing mode, let me
just pull up that particular post and try and make it a
little bit bigger.

Just so folks know what I'm talking about here.
So if you go to our blog, which is at
apiblog.youtube.com, you can just search for list, just
like I just did, and you'll find this blog post.
And we talk about how you could use our standard
icon-embedded player, but use some parameters over here that
let you say, OK, I would like the player to be populated
with all the uploads within this user name, Google
Developer, in this case.
The other types of values that you can do is say, I would
like this to be populated with all the
videos in a given playlist.
So you say playlist over here and you put in playlist ID
right over there.
And you'll automatically get a player that will load up
everything in the playlist and play those back to your users.
It is actually kind of nice because you get these little
thumbnails on the bottom when you zoom in even more, so you
can see these thumbnails that I'm talking about.
So you can get these thumbnails of all the
different past videos so users could just jump to the
specific one that they want to go to.
Let me start with Google Git engine in this case.
So that's kind of our recommended way of doing it
without having to write too much code of your own.
If you did want to write more code, feel free to do so.
And you can use our Data API, for instance, to get the
contents of a given playlist or the contents of user upload
speed, and then take all those video IDs and represent them
in any fashion that makes sense to you.
That's kind of really up to the developer.
JAREK WILKIEWICZ: Great.
Thanks, Jeff.
There was one question asked by someone on the live stream.
Where can they find more information about the API?
Jeremy, since I know you've been right in the middle of
trying to figure out all the intricacies of the API, where
would one start?
From your experience, what's a good starting point?
JEREMY WALKER: Well, if you look on the site where you'd
normally get the Version 2, there's actually a Version 3
link right above it that says experimental.
And you can go into that.
There's some good examples in there that I, in fact, started
playing around with.
And also great documentation that breaks down all the parts
that Jeff went over and how to get different parts of that
back in your responses.
So if you just go to the main YouTube API page, you'll see
it under the Data API section as Version 3, Experimental.
JAREK WILKIEWICZ: Thanks, Jeremy.
I know you've been studying it very carefully.
All right.
So we're almost out of time.
There's one final note that I wanted to make.
If you guys would like to help us with developer activities,
we are hiring.
If you go to developers.google.com/jobs,
you will see some of the positions that
we have on our team.
It is a lot of fun, and as you can tell, there's a lot of new
APIs coming out.
We work with a lot of developers, entrepreneurs,
large, small companies.
We engage in the community online, live Hangouts.
So a lot of different types of things that you might find
interesting.
So if you would like to check it out, please do so.
And I think this wraps it up for today's episode of Google
Developers Live and YouTube Developers Live.
Thank you very much for your time.
And we'll see you next week.
10 o'clock AM, Wednesday, Pacific.
JEREMY WALKER: Thanks.
JEFFREY POSNICK: Bye, everybody.
JAREK WILKIEWICZ: Bye.
[MUSIC PLAYING]