Видео YouTube на сайте через API: идея, ID, запрос, кэш, квота
Сайту нужны ID роликов и аккуратный кэш, не парсинг страницы канала. Встройка плеера и запрос к Data API — разные слои. Это схема для собственника и продакта, н
Поставить одно видео на страницу можно встройкой плеера: вы знаете ссылку, гость нажимает «смотреть». API нужен, когда список должен обновляться сам: новые ролики канала, серия уроков, видео на карточке товара. Это не туториал с копипастом ключей и не реклама YouTube.
Проект Google Cloud → включённый Data API → идентификаторы канала и видео → сервер периодически запрашивает список → ответ кладётся в кэш сайта → страница отдаёт гостю кэш и плеер. Embed показывает ролик. API поставляет каталог и метаданные. Поиск search.list на каждого посетителя сжигает дневную квоту. Секреты не в HTML.
Два слоя, которые путают
| Слой | Что делает | Чего не делает |
|---|---|---|
| Embed / плеер | Показывает конкретный ролик по ID | Сам не узнаёт, что на канале появилось новое |
| Data API | Отдаёт списки и поля (название, обложка, ID) программе | Не заменяет плеер и не даёт безлимитный парсинг |
Пять статичных роликов годами — вставьте плееры вручную. Каталог из десятков единиц с еженедельным пополнением — имеет смысл API плюс кэш. Интернет-магазин сначала должен принимать заказ; видео на карточке не чинит пустой checkout.
Что собрать до разработки
- Проект Cloud компании и включённый YouTube Data API — см. определение API.
- Channel ID (и при серии — playlist ID), не только «красивое имя канала»: имя меняют, ID стабильнее.
- Решение: ключ с жёсткими ограничениями для узкого публичного чтения или серверный OAuth, если нужны закрытые данные.
- Где хранить кэш: не в браузере каждого гостя как единственный источник.
- Что показывать при отказе API: старый кэш, заглушка, не пустая страница.
Логика запроса — без секретов в буфере обмена
Сервер (не страница гостя) вызывает метод списка роликов канала или элементов плейлиста — точное имя метода и параметры берите из текущей справки Google: они меняются. В ответе забирают videoId, заголовок, превью, дату. Это сохраняют у себя. Публичная страница читает вашу базу, не Google. Ключ или токен живут в переменных сервера, не в репозитории и не в чате.
На 21.09.2026 в публичной документации Google для проекта по умолчанию: 100 search.list в сутки, 100 videos.insert в сутки, 10 000 единиц в сутки на остальные методы; сброс в полночь PT; запрос ≥ 1 единицы. Если витрина ходит в поиск на каждого гостя, лимит кончится днём. Кэшируйте. Цифры перепроверьте перед релизом.
Кэш и обновление
- Выбрать интервал: раз в час, раз в сутки — по частоте публикаций, не «в реальном времени любой ценой».
- При ошибке квоты или сети отдавать последний удачный снимок.
- Не обновлять кэш с карточки товара при каждом визите покупателя.
- Новый ролик на сайте может появиться с задержкой — заложите это в ожидания редакции.
- Смена канала или плейлиста — смена ID в настройках, не «поиск по названию компании».
Права, превью, скорость страницы
Встройка идёт по правилам YouTube: логотип, ограничения, возрастные заглушки — не вырезайте элементы плеера в обход. Тяжёлая страница с десятком живых плееров сразу тормозит магазин: превью из кэша, плеер по клику. Музыка и чужие ролики без прав — юридический риск, API его не снимает.
UTM на ссылке «смотреть на YouTube» можно поставить, если ведёте на ролик как на посадку. Это подпись канала, не замена события покупки на сайте.
- Понятно, зачем список живой, а не пять статичных вставок.
- Channel/playlist/video ID записаны, проект Cloud — компании.
- Запрос идёт с сервера, кэш есть, секрета в HTML нет.
- search.list не стоит на горячем пути витрины без нужды.
- Квоты сверены с Google; отказ API не роняет страницу заказа.