Как получить ключ Google API (для YouTube API, Google Sheets API и т.д.)

Для того чтобы пользоваться сервисами Google API (YouTube API, Google Sheets API, Google Docs, Drive и т.д.), с использованием любого языка программирования, необходимо:

• создать проект в Google Cloud Platform,
• подключить нужные API (а их у Google много),
• прописать OAuth consent screen,
• получить ключи доступа,
• и провести ещё ряд настроек (безопасность, ограничения доступа),
• нужно соблюдать правила,
• укладываться в лимиты (quotas) и контролировать их.

В некоторых случаях нужно пройти модерацию проекта в Google Cloud Platform чтобы нормально работать. При этом Google любит менять как правила, так и интерфейс. Инструкции написанные в прошлом году могут не работать совсем или местами. Как в этом всем разобраться?

Я в своем сериале про работу с YouTube API уже делал два видео (1, 2) о создании проекта в Google Cloud Platform и получении ключей. Но понял что уже пора их дополнить, и более внятно систематизировать в виде отдельной статьи и отдельного видео, что я и делаю ниже.

Примеры использования Google API на практике смотрите в плейлисте, а сегодня чисто интерфейс Google Cloud Console.

Скорее всего со временем что-то в ней устареет, но текст проще править и/или дополнять, чем видео. Кроме того тут главное «воткнуться» в идеологию Google Cloud Platform и тогда все изменения будут восприниматься легче. Поскакали!

Видео версия — все то что в тексте ниже и немного больше

Создание проекта в Google Cloud Platform

Сначала вам нужен обычный аккаунт в Google. Иногда полезно завести отдельный аккаунт Google специально для приложения. Залогинься под этим аккаунтом в браузере и перейди в Google Cloud Platform по ссылке https://console.cloud.google.com/.

Регистрация в Google Cloud Platform

Если ты в свежем аккаунте и раньше Google Cloud Platform в этом аккаунте не пользовался, то сначала придется придется пройти регистрацию. Это не больно и нужно сделать один раз.

Это кадр из первого видео про создание приложения в Google API.

Создание Проекта в Google Cloud Platform

Затем нужно создать Проект в Google Cloud Console. Название произвольное (без кириллицы), но лучше внятное, чтобы ты потом, через полгода, вспомнить где этот проект может быть используется. Ведь в одном аккаунте может быть до 10 проектов и иногда проекты приходится удалять. Бывает сидишь и думаешь можешь ты удалить этот проект или он где то используется, поэтому удалять нельзя (хозяйке на заметку — просмотр квот может помочь в этом диком случае).

Создание OAuth consent screen

Это важнейшая, по мнению Google, часть проекта. Она описывает что будет делать приложение и как работать с пользовательскими данными. Здесь же вы должны подготовить Описание приложения, которое будет показываться пользователям если приложение будет запрашивать у него какие либо разрешения (доступ к его гугл диску или к его комментариям на ютюбе).

User Type

Первое что заполняем — это ограничение пользователей приложения. Если вы делаете Проект для ограниченного круга пользователей аккаунты Google которых объедены в Google Cloud Organization (Google Workspaces), то выбираете Internal. Но в большинстве случаев наш выбор External. Зачем делать этот выбор?

Internal проекты не нужно отправлять на модерацию в Google. Проект полноценно работает для всех пользователей вашей организации. Это удобно, например, когда вы делаете что-то вроде CRM с использованием Google Docs, Google Sheets, Google Drive. Пришел новый сотрудник, админ закинул его в Google Workspaces и он полноценный пользователь вашего приложения. Чтобы выбрать этот пункт нужно чтобы у вас уже была организация в Google Cloud. Иначе этот пункт будет не доступен для выбора.

External проекты могут быть доступны неограниченному кругу пользователей. Не нужно никаких Google Cloud Organization, ваше приложение просто спрашивает у юзера разрешение на изменение его Google Sheets и этого достаточно. А пользователь может, при необходимости, отозвать разрешение у вашего приложения когда сочтет нужным. Однако чтобы Проект так работал его нужно отправить на модерацию в Google, и не факт что проект эту модерацию пройдет. А в режиме теста некоторые функции Проекту могут быть вообще не доступны (например загрузка видео в паблик на YouTube через YouTube API). И круг пользователей ограничен сотней Google аккаунтов, которые ещё и нужно добавлять в проект вручную и невозможно удалить.

Иногда можно делать приложение, а для полноценного его использования просить юзера создать Проект в его Google Cloud Platform и подгрузить в проект ключи. Но это, сами понимаете, доступно не каждому пользователю.

Итак я выбираю здесь External.

Регистрация проекта в Google Cloud Platform

То что вы укажете в этом окне будет видно пользователям приложения во время запроса разрешений. Если вы планируете делать приложение публичным (в том числе отправлять его на модерацию) я бы порекомендовал внимательно отнестись к его заполнению. Я же обычно из тестового режима приложения не вывожу и заполняю эти поля как придется — на работу в тестовом режиме все это не влияет (ну кроме домена в некоторых случаях).

Scopes Проекта — должны быть минимальными чтобы не просить у пользователя слишком много и не отпугивать. Также слишком много запросов на разрешения могут усложнить прохождение модерации. Для приложения в тесте я здесь не заполняю вообще ничего, а разрешения запрашиваю уже из кода на Python, PHP или C#.

Тестовые пользователи проекта. У приложения в режиме теста есть ограничения по ряду методов в ряде API Google Cloud. Некоторые из них доступны только тем Google Account что добавлены в Test Users.

Важно! Единожды добавив тестового юзера в список его уже нельзя удалить!!!

После заполнения OAuth consent screen наступает самый важный момент — создание ключей.

Создание Credentials

Это крайне важный момент правильной настройки приложения Google Cloud Platform. Я сам долгое время не понимал принципов, поэтому настоятельно рекомендую разобраться, в том числе почитать официальную документацию.

Для того чтобы наше приложение могло обращаться к API Google Cloud нужно идентифицировать приложение и создать в коде сущность от имени которой приложение будет взаимодействовать с API Google Cloud. Для этого в окне Credentials нужно создать как минимум 1 идентификатор (ключ, токен) которое затем нужно использовать в вашем коде. В окне Credentials вы видите 3 типа идентификаторов API Keys, OAuth 2.0 Client IDs и Service Accounts. Для разных методов разных API могут быть нужны разные идентификаторы, в некоторых случаях достаточно простого API Key (который может быть вечным), а случаях когда приложение использует пользовательские данные или работает от имени пользователя нужно использовать OAuth 2.0 Client ID и запрашивать у пользователя разрешения.

Давайте проще на конкретных примерах:

• я хочу получить список опубликованных видео на YouTube по поисковому запросу (метод YouTube Data API search.list) — тогда мне достаточно API Key
• я хочу удалить видео на канале (videos/delete) — мне нужен OAuth 2.0 Client ID и перед обращением к методу удаления я буду должен запросить разрешения у владельца канала. Запросить доступ используя только API Key я не смогу.
• я хочу редактировать уже созданную таблицу Google Sheets — я могу использовать OAuth 2.0 Client ID (с запросом разрешений), но проще создать Service Account и тогда пользователь сможет предоставить нужный доступ к конкретной таблице только конкретному сервисному аккаунту.

Ключей можно создать много, их можно отзывать, к ним можно применять многочисленные ограничения доступа. Это гибкий и функциональный инструмент.

Как создать API Key

Жмем кнопку + CREATE CREDENTIALS, затем выбираем API Key, появляется окно с ключом. Ключ создан и им можно пользоваться. Созданный ключ можно удалить или отредактировать для ограничения доступа по ряду условий (доступ по IP, доступ по приложениями, доступ к конкретным API Google Cloud). Ключ вечный, обновлять его не нужно.

Если нажать на REGENERATE KEY, то токен (значение ключа, набор символов) изменится и все приложения которые использовали этот ключ работать перестанут.

У меня есть подробное видео использования API Key с YouTube Data API на Python.

Как создать Service Account

Жмем кнопку + CREATE CREDENTIALS, затем выбираем Service Account, появляется окно где обязательно нужно заполнить только два поля:

• название любое
• псевдоемейл сервисного аккаунта — почти любое из доступных
• остальные пункты — это дополнительные ограничения и роли аккаунта, я в реальной жизни ими не пользовался ни разу

Для работы с сервисным аккаунтом обычно достаточно знать его емейл. Например для выдачи нашему приложению разрешения редактировать Google Sheet нужно просто расшарить таблицу на емейл сервисного аккаунта.

Пример использования сервисного аккаунта

У сервисного аккаунта значительно больше настроек чем у API Key. Самый важный раздел PERMISSIONS, но это тема для отдельного и большого разговора.

Как создать OAuth 2.0 Client ID

OAuth 2.0 Client ID предоставляет наибольшее количество возможностей, однако и более сложен в обращении на всех этапах от создания, до использования в приложениях. Именно с этим ключом приложение может делать в пользовательском аккаунте почти все:

• создавать, редактировать и удалять документы (Google Docs, Sheets, видео и комментарии на YouTube)
• получать статистику по ресурсам (например YouTube каналы) которыми владеет пользователь
• менять ресурсы (описания, названия)
• может банить пользователей и менять права доступа для своих ресурсов
• и много другое в зависимости от API, которых в Google Cloud Platform множество

При условии что приложение запросило разрешение у пользователя и пользователь это разрешение выдал.

В некоторых случаях Google накладывает дополнительные ограничения на действия приложения в режиме теста, не прошедшее модерацию.

Чтобы получить OAuth 2.0 Client ID также жмем + CREATE CREDENTIALS, а затем Create OAuth client ID. Здесь важно выбрать верный тип приложения которое будет использовать создаваемый ключ. Если с Android, iOS, Chrome App, UWP все понятно, то что выбрать Web App или Desktop порой не сразу ясно и я поясню в видео на 30:57, а пример использования Create OAuth client ID на примере YouTube Data API на Python можно посмотреть в этом видео.

Какие ключи выбрать то в итоге для приложения

Все просто! Если ваше приложение только лишь читает общедоступные данные не связанные с личными данными пользователей,  то, скорее всего, вашему приложению будет достаточно API Key. Тогда используйте именно его и создавайте ключи под разные задачи. В остальных ситуациях предпочтителен сервисный аккаунт и только если его не хватает методу (а это может быть явно указано в документации к методу) используйте Create OAuth client ID.

Подключение нужных API

Ну и финальный аккорд — это подключение к приложению в Google Cloud Console нужных нам API. Принципиально вы можете создавать под каждое API свое приложение, а можете в одно приложение подключить почти все API и пользоваться одними токенами под все задачи. Как вам удобнее так и делайте. Но я предпочитаю разделять.

Подключить API просто идем в раздел Library и добавляем нужное API.

Про квоты

У каждого проекта в Google Cloud Console на каждое API если определенные лимиты, называемые квоты. Когда приложение использует методы API, отправляя запрос эти квоты (points) расходуются. Расходуются они даже если запрос был не успешным. Квоты выдаются на проект, и в каждом аккаунте Google Cloud Console может быть до 10 проектов.

Тут есть прием, незатейливая хитрость, которая позволяет вам увеличить вам квоты попробуйте догадаться как и напишите в комментариях.

Квоты можно посмотреть на Dashboard проекта и в разных местах Google Console — просто наберите в поиске консоли quotas.

У каждого API есть свои «тарифы», например Калькулятор квот для YouTube Data API. Перед разработкой стоит посмотреть какие методы сколько квот потребляют, как оптимизировать приложение с этой точки зрения и как отлавливать превышение лимита квот. Особая боль в том что ни в каком из API нет методов для проверки остатков квот, а Google в свою очередь может забанить приложение которое будет долбиться с превышением.

Сериал по работе с Google API 

Я давно работаю с разными API Google (хотя гуру себя далеко не считаю), некоторое время назад я начал делать видео где рассказываю о своем опыте и экспериментах (все сугубо имхо, но многое выстрадано). Уже снято про YouTube API, на подходе ещё серии про Google Sheets API, возможно будет ещё что-то и все это собрано в плейлисте Google API, я стараюсь отвечать на все комментарии к видео, готов помочь или принять конструктивную критику. Так что велкоме!