Read More

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

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:
Read More

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.

After installing the SDK, you can open Visual Studio 2008 and select the YouTube template to get started writing your own code.

This packaged SDK no longer contains any source code, but it's all available from the project's Subversion repository. The YouTubeUploader source code is of specific interest to developer who want to see the ResumableUploader component in action.

To file bug reports or make feature requests, please use the project's Issue Tracker.

Regards,

—Frank Mantek, Google Data APIs Team

Read More

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

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

Read More

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