Google Data

By Xavier Damman, co-founder of Storify

(Cross-posted from the Google Code blog, where the post is part of Who’s at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.)

Storify is part of the Google I/O Sandbox. Please come say hi to find out more about how you can leverage our APIs so your users can remix your content to create stories to share on social networks.

Storify provides a super simple drag and drop user experience to create stories using elements from the web: tweets, YouTube videos, Facebook updates, SlideShare presentations, audioboo files, and so on (see Storify in action here). This post explains how we incorporate videos in Storify using YouTube Data API and Player API. All the code snippets are in JavaScript. In fact, our full stack is in JavaScript: we use NodeJS and MongoDB which we think is an über cool mix.

The source of the source

To create a Storify source, we need to be able to get a feed of results using JSONp (basically JSON with a callback function so that you can do cross domain calls; from the YouTube API perspective this is the JSON-C format). For YouTube, the main search API endpoint looks like this:

request: function(formdata) {
   return {
      'url' : 'http://gdata.youtube.com/feeds/api/videos',
      'params': {
         'v'  : 2,
         'max-results' : 20,
         'alt'  : 'jsonc',
         'q'  : formdata.keywords
       }
    };
  }

This function is called when the user clicks Submit in the search tab of the YouTube source in the Storify Editor. The main controller executes the request and sends the JSON result to the results method, which returns an array of normalized results:

results: function(json) {

  if (json.data && json.data.totalItems && json.data.totalItems == 0) {
    throw "No results found";
    }

  var videos = json.data.items;
  var results_array = [];

  for (var i = 0; i         var normalizedResult = {
           permalink   : 'http://www.youtube.com/watch?v='+videos[i].id,
           source  : 'youtube',
           elementClass : 'video',
           metadata  : videos[i],
           thumbnail   : videos[i].thumbnail.sqDefault,
           title: videos[i].title,
           description  : videos[i].description.substr(0,140),
           author: {username: videos[i].uploader },
           created_at  : videos[i].uploaded,
           oembed: {html: '

Thanks to this normalized representation of a story element – in this case, it’s a video object – we can build an object-oriented story as the user drags and drops any of these elements. This technique has multiple benefits: we maintain attribution to the original content creator, and we can track the content as it spreads across the web (how many times it has been seen and from where).

The story element also provides the oEmbed HTML code. This is used to render the video embed when the video is added to the story. For that purpose we use the YouTube Player API with their new iframe embed.

Story.json

We have a very simple way to get any data out of our platform: just append .json to any storify.com URL and you get the JSON representation of the content of that page.

For example:

• http://storify.com/latest.json?topic=googleio returns the latest stories with the tag #googleio

• .

• http://storify.com/xdamman.json returns the user object and the user’s latest stories.
• http://storify.com/xdamman/googleio.json returns the story object of the story “GoogleIO” of xdamman. You can use this to easily filter the elements of the story to retrieve only the YouTube videos of a given story and create a fancy HTML5 visualization (see the slideshow or this version). You can see some open source examples at http://github.com/storify/templates.

Add the Storify Editor to your site

The Storify Editor can be called in an iframe. You just need to provide a callback parameter, like this: http://storify.com/story/new?callback=yoursiteurlcallback. The user will be asked to authenticate with Twitter and then will be able to create a new story. Once the user is done and hits “Publish”, we call you back, passing you the permalink of the new story created:
yoursiteurlcallback?permalink=storyPermalink.

You can then either fetch the JSON of the story by appending “.json” to the storyPermalink or you can embed the story by loading . This is a great way to provide your community with a way to create stories right from your site.
This is only the start. We plan to open a Sources API so that any developer can build a source for any service. Please come see us at our booth at the Google I/O Sandbox if you’re interested in joining our developer community. And check out this article in the New York Times to learn more.

Come see Storify in the Developer Sandbox at Google I/O on May 10-11.

Xavier Damman is the co-founder of Storify. He is also the founder of HackDemocracy, a community of hackers who want to improve our democracies using technology.

• Use the Advanced Account Settings tool to select which channel should be used. This is recommended when a user has one channel they want to use for all applications.
• Set up login credentials for each of their Google+ pages, and specify those credentials, not their normal Google Account credentials, for each application that needs access.

• OAuth 2 will automatically display a “Select an account” web interface, allowing users with multiple channels associated with their account to choose which one they’re authorizing access to.
• • …this doesn’t apply to Android OAuth 2, yet.
• Use of other authorization methods will mean some users need to specify which channel to use, either in their Advanced Account Settings (if they consistently use one channel), or by setting up login credentials for each channel, and using them as needed.
• All developers are strongly encouraged to display visual feedback letting their users know which channel is currently authorized.

—Jeff Posnick, YouTube API Team

For almost a year, we’ve been recording weekly shows for YouTube API developers as part of the Google Developers Live series, hosted on the Google Developers YouTube channel. Now, if you want to get just YouTube API-related videos, check out the new YouTube for Developers channel.

Long-time readers might remember a blog post from a while back entitled “ClientLogin #FAIL”, in which we covered the myriad ways in which your ClientLogin authorization attempts might result in an error. Even though ClientLogin has been officially deprecated since April 2012, and even though we’ve been recommending that developers switch to OAuth 2 for longer than that, we know there are still a good number of legacy applications out there that still rely on ClientLogin.

If you are a developer of such an application, there’s another thing that you (and your users) will need to start watching out for: at some point in the future, we will start requiring that the username parameter passed to ClientLogin (i.e. what’s referred to as the Email= value in the ClientLogin request) correspond to the full email address of the Google Account that’s associated with an underlying YouTube channel. We’ve supported using Google Account email addresses with ClientLogin for many years now, ever since we started linking Google Accounts to YouTube channels, but old habits die hard, and many users still use YouTube usernames.

We haven’t yet determined a date for when we still stop supporting ClientLogin with YouTube usernames and will provide additional details when we know more about when it will take place. However, if you use ClientLogin, it’s not too early to start encouraging your application’s users to start providing their Google Account email addresses instead of their YouTube usernames when logging in. If you have the ability to update your existing application’s user interface, we recommend doing so to indicate that the username field should take a Google Account email address. If you have any online help materials or technical support for your software, update them to ensure that users know to provide their Google Account email address.

Users who log in via the YouTube.com web interface, or who go through the AuthSub, OAuth 1, or OAuth 2 web authorization flows will soon be required to use their Google Account email address instead of their YouTube username as well. This web-based transition will take place well before we deprecate YouTube usernames for ClientLogin, and it should be transparent to developers since Google controls the user interface for these flows. For more information, see this help center article.

As mentioned, we’ll have a follow-up post in coming months with more details about exactly when we’ll stop supporting YouTube usernames with ClientLogin. That post will also communicate the exact error message that ClientLogin will return when a YouTube username is used. We’d like to close with one more plea: ClientLogin is deprecated, and is technically inferior to OAuth 2 in a number of important ways. Our new Google APIs client libraries provide first-class OAuth 2 integration that developers can take advantage of in their new code, or back port to their existing code. You will be doing your users a service and making their accounts more secure by transitioning from ClientLogin to OAuth 2.

Update (June 2013): The change mentioned in this blog post is now in effect. Attempts to use ClientLogin with a YouTube username will result in HTTP 403 Forbidden responses, with Error=BadAuthentication in the response body.

Cheers,
—Jeff Posnick, YouTube API Team

—Jeff Posnick, YouTube API Team

Many of you are already familiar with the terrific Stack Overflow website, which has become the de facto resource on the web for all types of programming questions. And many of you have been asking YouTube API questions on Stack Overflow for some time now, but haven’t received any official responses from the YouTube API Developer Relations team. That’s because, for the past five years or so, our focus has been on providing developer support via our dedicated Google Group. We’ve decided that instead of continuing to maintain a dedicated Google Group for YouTube API questions, it would help more users if we focused on responding to Stack Overflow posts.

We encourage all developers who have questions about the YouTube API to start posting on Stack Overflow today using the tag youtube-api. You can use this new question template to pre-populate the tag for you so that you don’t forget. While we’ll do our best to find and answer relevant questions that aren’t tagged with youtube-api, you’d be making our job easier (and you’d get a quicker answer) if you tag things correctly from the get-go.

Here are a few tips for folks new to Stack Overflow:

1. Before posting, search to make sure your question hasn’t been asked before. To do this, put [youtube-api] as the first part of your search, then type in some keywords that describe your problem or question.
2. If you need to ask a question, make sure you apply the youtube-api tag, as well as the tag that indicates the language that you’re using. If you’re using PHP to access the API, your question should be tagged youtube-api as well as php.
3. Make sure you watch your question after posting it, as experts that can provide you with an answer might leave comments to ask you for clarification.

Stack Overflow prides itself in being a destination for questions and answers, and not a place to file bug reports or feature requests. We ask that developers do not post on Stack Overflow for those sorts of things, and instead make use of the templates we have for filing a bug or filing a feature request in our existing public issue tracker. (Be sure to check the list of existing open issues before filing a duplicate.)

On October 15, we’ll be switching the existing discussion Google Group into archive-only mode, meaning that it will no longer accept any new posts. You don’t have to wait until October 15 to start asking questions on Stack Overflow or to file reports in the issue tracker, though.

For those developers who mainly “lurked” in the discussion Google Group and used it as a way of getting official announcements about the YouTube API, we have a number of other communication channels to recommend. Subscribing to this blog’s RSS feed is a great idea, for instance. You can also follow us on Google+ at http://google.com/+YouTubeDev. If you’d like to submit a question to one of our weekly YouTube Developers Live broadcasts, you can do that for the next upcoming scheduled show. Finally, for those who prefer to get updates via email, we will be keeping the announce-only Google Group active, and we’ll continue to post important messages there.

Cheers,
—Jeff Posnick, YouTube API Team

Update: This change also applies to  tags, which were not mentioned in the original announcement.

If you follow the YouTube Creator Blog, you might have recently seen a post announcing that video tags (also known as keywords) would no longer be displayed to viewers of a video on YouTube’s website. They aren’t going away from the video itself, though—the owner of the video can still create tags for new videos and edit tags for existing videos, and video tags will still provide an important signal used to surface relevant results when searching for videos.

We’re going to be making some corresponding changes to all versions of the YouTube Data API to mimic this behavior in API responses. Starting later today, August 28, on the staging server and September 4 on the production server, any time you get a video entry back from any API method, it will have an empty element. This is a valid response from the API that your application should already handle gracefully, since videos are not required to have any keywords to begin with.

The exception to this rule is when you make authenticated requests to the API, and you request a video entry that’s owned by the currently authorized user. In that scenario, you will get back a element that contains the full list of tags for the video, and you can read, update, or remove those video tags using the standard API operations.

Important: If your application allows video owners to update the metadata of their videos, please ensure that you include the proper Authorization header for both read and write operations. Otherwise, you could accidentally return an empty list of video tags when retrieving an existing video, and end up overwriting the video’s tags if you update the metadata. Video tags continue to play an important role in helping viewers discover your videos when searching on YouTube.com or via the API, so if your application does support metadata editing, please make sure you allow owners to tag their videos properly.

Cheers,
—Jeffrey Posnick, YouTube API Team

It’s Presidential election season in the United States, and YouTube’s News and Politics team is partnering with Storyful to highlight timely political videos from across the country. With that in mind, we’re excited to announce that citizen journ…

YouTube Insight reports provide video owners with statistics about their viewership above and beyond public view count information. They’re a crucial tool when you want to find out more about the demographic or regional breakdown of your videos’ vi…

We’ve got some exciting additions to the list of supported search parameters for YouTube feeds that should make it easier to narrow down your search results to exactly the videos you’re looking for. Each of these search parameters has an accompanyi…

While the YouTube embedded single-video player has seen a number of improvements in the past few months, the embedded playlist player has lagged behind—until now. We’re happy to introduce a completely rewritten embedded playlist players, ready for …

YouTube previously offered a specialized way of embedding playlists (as well as uploads and favorites feeds) for playback on third party sites in a customizable interface—we called this the Custom Player. While the Custom Player had its fans, it neve…

(Cross-posted from The Official YouTube Blog.)It may be hard to imagine but YouTube’s video preview images represent to many the ultimate deciding factor as to whether or not they watch a video. If a preview image looks interesting, it can mean the d…