youtube-eng.blogspot

Extended Access Controls Available via API

Tuesday, February 23, 2010

One of the feature requests that we've received most frequently from developers it to have a YouTube API call that enables or disables commenting for videos. It's a logical request — videos can be automatically uploaded via the API, and having to visit youtube.com from a web browser to modify the commenting settings manually doesn't make much sense.We've taken action on this feature request, and gone one step further: the new <yt:accessControl> element lets video owners enable or disable video rating, comment voting, video responses, and off-web syndication in addition to commenting. We've also taken an existing element for controlling embedding, <yt:noembed>, and migrated its functionality to <yt:accessControl>. Existing code that uses the <yt:noembed> element will continue to work as per our API deprecation policy, but <yt:accessControl> is preferred for new development.You can set access controls for a video when uploading or updating a video. See the Setting access controls for a video section of the Developer's Guide for more information.With the addition of the this feature, the YouTube API now offers parity with all the settings available via the YouTube web interface. We hope that applications that support YouTube uploads take advantage of this new functionality, and we know your users will appreciate it!Cheers,-Jeff Posnick, YouTube API Team

Announcing the YouTube SDK for .NET

Monday, February 22, 2010

I am happy to announce a new resource for the .NET fans in the YouTube developer community. The YouTube Software Developer Kit for .NET contains all you need to get you started with the YouTube API using Visual Studio 2008.

The SDK includes a help file, a project template and the following sample programs:

An application that use the Simple Update Protocol to watch for YouTube activity from a group of users.

An example ASP.NET website that illustrates the use of AuthSub authentication.

A bulk uploader tool that uses the new ResumableUploader component to asynchronously and reliably upload video files. Multiple threads are used to process video metadata, which is read from a CSV file.

Subversion repositoryYouTubeUploader source codeIssue Tracker—Frank Mantek, Google Data APIs Team

Best Practices for Avoiding Quota Issues

Tuesday, February 9, 2010

Like most publicly-available web services, the YouTube API implements a quota system to protect our servers from excessive traffic. This traffic might result from a harmless typo – who hasn't written an infinite loop or two after a long night of coding? – or it may result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the YouTube API. It ensures that one developer's actions cannot negatively impact the larger community.
That being said, we've recently made some changes to the way we implement YouTube API quotas. Our previous quota implementation was a bit too coarse-grained for some common usage scenarios. For instance, if an application running on a common web hosting platform generated excessive requests, it could end up blocking other applications running on the same servers that were generating only a modest amount of traffic.
We believe that our new quota implementation is much more straightforward and less likely to negatively impact applications that are "doing the right thing." The new quota system ties usage to a specific developer key; as long as your application includes a developer key along with your YouTube API requests, your requests will be less likely to be flagged for quota violations.
It's also worth noting that different types of API operations count differently towards quota calculations. In general, you can safely make more frequent HTTP GET requests to retrieve data than HTTP POST/PUT/DELETE requests to modify data.
In the unlikely event that you do get flagged for excessive API requests, you'll receive an HTTP response with a code of 403 and a response body that includes
<errors><error><domain>yt:quota</domain><code>too_many_recent_calls</code></error></errors>
It's up to your code to detect this error and take appropriate action. As a best practice, we recommend stopping all API calls from your application for 10 minutes after receiving such an error in order to "reset" your quota. When you resume making API calls, you should scale back on the frequency of your requests. As a rule, API requests that do not originate from user interaction – requests made one right after another as part of a background synchronization or bulk import process, for instance – are more likely to trigger quota violations, so they should be avoided.

Update: Watch a YouTube Developers Live broadcast devoted to quota best practices:

Cheers,-Jeff Posnick, YouTube API Team

A New Format for JSON Results

Monday, February 1, 2010

It's been two and a half years since we announced JSON as an alternative output format to Atom XML for YouTube API responses. As illustrated in the developer's guide and codelab, JSON-formatted data is a natural choice when writing web applications – after all, who wants to parse XML from JavaScript?

Our existing JSON format isn't perfect, however. It's very much a literal translation from Atom. As is often the case with literal translations, the current JSON format is wordier than it needs to be, and it lacks some of the elegance that a native dialect would offer.

We've rethought out current JSON implementation, and moved away from a literal representation of the Atom data to a format that we hope will be more pleasing to those who are fluent in JSON. The vestigial XML namespace prefixes are no more, and we've removed many pieces of metadata specific to Atom documents that come across as noise in JSON. Repeating data elements are always structured as true JSON lists, and useful video metadata that exist as XML attributes in Atom have been rearranged to make more sense in the JSON document. You'll also find that the new JSON results are more compact than Atom XML, which is of special importance to code running from limited-bandwith mobile applications.

We call this new format JSON-C, and you can read about all the technical details in our documentation and see it in action in our live demo.

With the release of JSON-C, we consider the legacy JSON format officially deprecated. All new development should prefer JSON-C to JSON, and if you have existing YouTube API code that relies on JSON-formatted results, you'll need to upgrade your code to use the new format. We will be supporting legacy JSON-formatted output in accordance with the deprecation policy outlined in our Terms of Service.

Cheers,

-Jeff Posnick, YouTube API Team

YouTube's APIs and Refresher on our Terms of Service

Thursday, January 14, 2010

It's been a busy 2009 and we're excited to be back in 2010 to work on all the cool features we have planned for the YouTube APIs in the coming months.
Opening up our API has led to some really cool and fun commercial applications, far beyond what anyone here at YouTube could ever have imagined. Tens of thousands of developers have created great apps and websites that not only entertain and delight users in creative ways but give our content partners more choice and reach in distributing their videos. For example, we recently announced YouTube Direct, an open-source video uploading platform that is built entirely on top of the YouTube APIs and is available to any commercial website that wants to solicit video submissions from their users.
We thought it would be a good idea to start the year by revisiting a subject that many of you have had questions about since the APIs were born: the API Terms of Service.
Launched back in 2007, the YouTube APIs provide access to some of YouTube's core features (uploading, searching and playing videos, organizing playlists, etc.) for your websites and apps. Before using the API, we ask that you do one thing: carefully read through our Terms of Service (TOS). Here are a few things contained in our TOS that you should be aware of.

Videos belong to their owners - YouTube is a hosting platform. The videos themselves belong to the content owner (anyone from a major studio to a mother recording her son's graduation). In all cases, the content owner decides how and where their YouTube videos are distributed. Sometimes, video owners don't want others to profit from their work, or sometimes they may want to restrict where their videos are shown. While you may disagree with this decision, we need to respect the content owners' wishes.

Standard YouTube video player is key - Consistency in terms of quick video loads and playbacks is a hallmark of the YouTube experience. We therefore ask that you don't enable videos for download, modify a video in any way, or enable playback through means other than other official embeddable players.

Don't serve or strip ads from the video - Serving your own ads against a video without sharing revenue with the content creator, or YouTube, is against the TOS. So is using technology that strips out the ads we're serving on videos. Doing this deprives the uploader from legitimate earnings from his or her work. If you want to learn more about monetizing your YouTube apps, check out our API monetization guide.

It's ok to charge customers to access your application - Creating a subscription, or a one-time access/download fee to use your website or app is fine. But if you do, make it clear that it's you who's charging for access to the video, not YouTube. If you don't make this clear, you're very likely violating the TOS.

Occasionally, we update our TOS to make things even clearer, or to evolve as new features become available on the Web. But rest assured that the core guidelines in our TOS related to advertising, downloading videos, and using an official player have been there since the TOS's inception.
YouTube APIs Developer ForumPosted by Kuan Yong, YouTube APIs and Tools Team

Enrich your site with YouTube Direct

Tuesday, November 17, 2009

Today we announced the launch of YouTube Direct, a new tool built on top of YouTube's public APIs that enables any developer to solicit video submissions on their website, powered by YouTube.

Users upload their videos directly on the developer's website, after which the developer can review the submissions and select the best ones to showcase. Since these videos live on YouTube, users are able to reach YouTube's large user base directly while also getting broader exposure and editorial validation for the videos they create.

Although YouTube Direct was originally created with our news partners in mind, we believe that other developers and website owners can benefit from it as well. To put YouTube Direct in the hands of as many developers as possible, we open sourced the bulk of the code and designed it to run on Google App Engine - Google's scalable hosting platform. This enables developers to easily deploy their own instance of the tool and take advantage of App Engine's scalability and low cost. The videos themselves are served from the same infrastructure that powers YouTube.com.

Visit YouTube Direct for Developers page to read more about it or go directly to the project page to download the code. As always, we'd love to hear your feedback on this new tool. Drop us a line in YouTube's Developer Forum.

New YouTube API Version Available for Testing

Tuesday, November 10, 2009

While we don't normally call out new releases of the Google Data YouTube API on this blog, we wanted to draw specific attention to the version that has just been pushed out to our staging servers. There are two specific changes that we'd like to give our developers and partners a chance to test before they go live. Both changes affect important areas of the API: ClientLogin authentication, and playback URLs in media:content entries.

We fully intend for the changes to be backwards compatible, and from the developer's perspective you should not have to change any code. But testing your code is always a best practice, so if you rely on ClientLogin or retrieving media playback URLs from the Google Data YouTube API, please repoint your code to http://stage.gdata.youtube.com and confirm functionality.

Any incompatibilities should be reported as soon as possible in our YouTube API Developer Forum. We expect to move the changes from the staging environment into production on November 17.

Engineering and Developers Blog