Tuesday, February 9, 2010

Best Practices for Avoiding Quota Issues

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