Для того чтобы пользоваться сервисами 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 и получении ключей. Но понял что уже пора их дополнить, и более внятно систематизировать в виде отдельной статьи и отдельного видео, что я и делаю ниже.
API для начинающих. Пример VK. [1/5]
Примеры использования 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, то токен (значение ключа, набор символов) изменится и все приложения которые использовали этот ключ работать перестанут.
Как создать 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, я стараюсь отвечать на все комментарии к видео, готов помочь или принять конструктивную критику. Так что велкоме!
Источник: azzrael.ru
Application Programming Interface (API) — Интерфейс программирования приложений, созданный специально для того, чтобы машине (компьютеру) было проще считать нужную информацию с сайта.
С помощью этих интерфейсов мы получаем какие-либо данные этого проекта, сервиса. Мы можем пользоваться их наработками, методами, программными решениями в своем проекте . В конечном итоге от использования API выигрывают все:
Разработчики получают готовые части (блоки), которые используют в своих проектах, достаточно лишь реализовать обращение к нужному API в коде. Для веб-приложения важно, чтобы данные отдавались в формате JSON, т.к. он более прост для обработки и чтения.
В рамках изучения языка Python мы уже сталкивались с API, когда работали с библиотекой Aviasales. Т.е. компания предоставляет возможность создавать свой полноценный проект по поиску авиабилетов или поиска отелей.
С помощью API удобно получать именно данные, а не какой-либо участок кода с ними. В API меньше кода — всё собрано в одном месте . Нет нужды парсить это регулярными выражениями. И API всегда будет работать, даже если источник поменял на сайте HTML-код.
Некоторые API предназначены для запроса или обновления базы данных, другие API добавляют функциональность в ваше приложение . Например, Sony производит камеры, которыми можно дистанционно управлять через веб-API, с помощью которого разработчики могут активировать затвор камеры.
Самый же яркий пример — это Google Maps . Вместо написания миллионов строк кода и лицензирования сторонних картографических данных для представления интерактивной карты в приложении разработчик может выполнить то же самое с помощью примерно 10 строк кода, которые используют API
Зачем компании создают API?
Конечно, в первую очередь используют API в своих целях. Например, для создания мобильного приложения для сервиса можно использовать API — это действительно удобно. Во-вторых, API — это своего рода Open-Source их проекта. Это значит, что тысячи (миллионы?) пользователей по всей планете могут дополнять приложение, писать под него отдельные клиенты или удачно модифицировать существующие. Это полезно как с технической стороны, так и со стороны лояльности юзеров и может привести к созданию крепкого комьюнити.
Где искать API?
Сервис programmableweb.com содержит в себе каталог различных библиотек API, которые вы можете использовать в своих проектах. Все они структурированы по назначению и доступны по ссылке в меню API Directory. В нём собраны, в том числе, и самые популярные: Google Maps, Twitter (интерфейс сервиса выдает информацию о твитах конкретного человека, его читателях и о тех, кто его читает, и так далее), Facebook и другие:
Всего категорий в ProgrammableWeb целых 486. Здесь действительно можно найти всё, что угодно: облачные решения, машинное обучение, платежи, аналитика, маркетинг, игры, образование, базы данных, интернет вещей, чаты, наука. Всё-всё-всё. Можете посмотреть сами.
Для тех, кто работает в Питоне с модулем JSON, особую ценность составляет строка Supported Response Formats, где описывается протокол, с помощью которого принимаются ответы от сервера.
В некоторых экземплярах есть обучающие материалы и примеры кода использования для различных задач с описанием:
API — это именно тот случай, когда не нужно изобретать велосипед. Использовать чужие библиотеки для своих проектов — нормальная и частая практика. Это упрощает логику работы приложения, тем самым освобождая программистов для написания других киллер-фич
Пример, через браузер можно напрямую обратиться к API GitHub (api.github.com/users/petrgazarov), даже без маркера доступа, и получить вот такой ответ в формате JSON:
Источник: digital2.ru
Как получают API?
Здравствуйте, вопрос может показаться не понятным, но я новичок в этом деле и до конца не понимаю, что значит API в целом и как его получить.
Мой знакомый рассказал в кратце, как получить какие-то запросы, с помощью которых можно будет взаимодействовать с сервером (или с приложением ), но их нужно найти в пакетах данных и если они зашифрованы, то нужно разобрать приложение и найти генератор ключа дешифровки… А потом я вообще ничего не понял.
Пожалуйста, расскажите простыми словами (аналогии приветствуются) что вообще происходит с этим API и что это вообще?
Что за запросы и как их можно получить, если код программы изменился и старые запросы (API, я просто не знаю как правильно поставить вопрос) стали недоступны?
Если понадобиться, то приложение на Java.
- Вопрос задан более года назад
- 184 просмотра
Комментировать
Решения вопроса 1
Delphi Developer, сис. админ
API (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай][1]) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой
По простому
API — это набор правил, по которым можно наладить связь между разными системами. Это то, что предоставляет некоторый сервис. Он же и разрабатывает его и он же даёт его в пользование.
Пример с той же погодой. Есть сервис — Погода. Он решил, что может предоставлять данные о погоде всем желающим.
Ты скажешь — «ну вот у них же сайт есть и там всё написано», но чтоб использовать данные о погоде в собственной программе придётся «парсить» целую страницу. Это не удобно, затратно и нестабильно.
Для этого разработчики разрабатывают набор правил, в данном случае — запросов. Выполнение которых будет возвращать строго определенную информацию.
Это же API может позволять вносить/модифицировать и удалять информацию (REST).
API как правило — это документация. Пример такой документации (API) для погоды — https://openweathermap.org/current
Если углубиться в вопрос, то ты столкнёшься с такими понятиями как токен или ключ, которые определяют уровень доступа к методам API. Некоторые API могут работать без таких вещей, но по большей части все используют токены. Хотя бы номинально.
API — позволяет делать только то, что реализовали разработчики. И если они не добавили методы, например, установки значения текущей температуры — ты не сможешь её изменить.
Ещё один момент, касательно топика — это не путать API и эмуляцию запросов с сайта сервиса. Т.е. смотреть, что вызывает сайт при работе («искать в пакетах») и вызывать то же самое — это не API.
Дополнительно
API — это не только про запросы. API — более широкое понятие нежели доступ к серверу.
Через API работают, например, все программы в Windows — WinAPI. Через API программы взаимодействуют между собой. Плагины в браузере используют API браузера для работы с плагинами.
Ответ написан более года назад
Нравится 2 2 комментария
дико извиняюсь, но в чём смысл таких ответов? я же написала тоже самое. я просто могу взять любой твой абзац и сделать цитату своим
Анастасия, ну. как бы нет. Я описал в более общем и понятном виде. Не суживая API до API сайтов.
Да и твой ответ во многом не точен, а многие вещи лишь с натягом можно посчитать истиной.
Ответы на вопрос 1
Начинающий программист
Я приведу самый простой пример с получением данных. По сути, у API возможности неограниченны. Всё что хочешь — то и можно. Просто чаще всего API используют, чтобы получить какие-то данные.
Принцип такой:
Есть сайт с погодой. Чтобы получить температуру в условном Питере, которую они замерили — тебе нужно зайти к ним на сайт, вбить в параметрах поиска СПБ и глазами посмотреть.
И вот, чтобы обеспечить потребность «знать погоду» — тебе достаточно просто заходить к ним на сайт. Но если ты хочешь, чтобы на твоём сайте/приложении/в игре — была погода, то тут возникнут проблемы
— По сути ты мог бы просто каждые 10 минут заходить на сайт погоды, брать от туда данные и загружать себе на сайт. Согласись — неудобно.
— Либо ты мог бы настроить бота, который бы заходил на сайт, симулируя пользователя и доставал бы из нужного блока температуру, а потом вставлял результаты тебе на сайт. По сути, так и делают, когда нет API, но это не совсем стабильный канал: а) тебя могут забанить по ip за странные запросы; б) если изменится вёрстка сайта (порядок блоков), то разумеется достать температуру ты уже не сможешь и придётся переписывать бота
— И тут на помощь приходит API. Принцип таков: ты можешь договориться с поставщиком температуры о том, что ты будешь брать у них данные. Это может быть как платная услуга, так и бесплатная (обычно зависит от кол-ва запросов). В итоге тебе дают ссылку, в которой указаны уже все параметры, которые тебе нужны и ты просто настраиваешь своего бота на то, чтобы получить эти данные по ссылке и вставить на свой сайт.
Чтобы посмотреть температуру в Санкт-Петербурге тебе нужно открыть ссылку:
http://api.openweathermap.org/data/2.5/weather?q=Санкт-Петербургunits=metrichttps://qna.habr.com/q/1013315″ target=»_blank»]qna.habr.com[/mask_link]