А вот и вторая часть нашей статьи, посвященной работе с социальными сетями. Готовы? Сегодня мы расскажем, как организовать код, чтобы добавление новой соцсети не вызвало особых проблем. Но прежде чем приступить, давайте кратко опишем общие моменты. Работая с любой социальной сетью, вы обязательно с ними столкнетесь.
Токены доступа
При авторизации соцсеть дает вам токены доступа. Это либо один токен, либо токен и ключ к нему. Их нужно использовать для выполнения запросов к API. Но эти токены могут перестать работать. В связи с изменением пароля или истечением срока. Поэтому мы рекомендуем всегда обрабатывать ошибки токенов и просить пользователей переподключать их к своим социальным аккаунтам.
Лимиты
Все социальные сети имеют свой лимит запросов. У некоторых он фактически незаметен (Facebook), а у некоторых довольно серьезен (Twitter). Обязательно ознакомьтесь с лимитами на запросы, которые собираетесь выполнять и добавьте логику, которая в случае превышения лимитов, отложит все запросы к соцсетям на определенное время.
Кэширование
Социальные сети довольно часто кэшируют информацию, поэтому вы можете столкнуться с несовпадением количества друзей в API ответе и самой социалке. Это вполне нормально. Если же вам кажется, что ошибка все же имеет место, обратитесь в техподдержку.
Pagination
Как вы понимаете, социальные сети объединяют огромное количество пользователей, генерирующих просто неисчислимое количество контента. Если бы они использовали стандартную пагинацию, мы бы наблюдали следующую ситуацию: пока юзер читает первые 10 постов из ленты, его контакты могут создать еще пять. И тогда на второй странице он бы увидел уже знакомые ему пять постов. Именно поэтому все социальные сети работают либо с курсором, либо с граничными параметрами.
Курсор — это та же страница, только вместо номера передается специальный ключ, который социальная сеть вернула в первом запросе. В последней странице этот ключ будет пустым. Это означает, что данных больше нет.
Граничные значения — это, как правило, timestamp или id записи. Они передаются вместе с каждым запросом, и пользователь не получает более новые посты, чем заданный ограничитель.
Как правило, все гемы из коробки работают с пагинацией. И вам достаточно всего лишь понимать ее принцип. Однако существуют нюансы, применимые для некоторых социальных сетей. Например, гем Twitter при обращении к списку друзей пытается вытянуть всех и сразу. Но если у контакта их больше, чем 3000 (15 запросов по 200 друзей), вас ожидает превышение лимита. В итоге операция завершится безрезультатно.
Совет: при работе с Твиттером используйте
https://dev.twitter.com/rest/reference/get/friends/ids
https://dev.twitter.com/rest/reference/get/users/lookup
Обращение в техподдержку
Даже у таких гигантов как Twitter или Facebook, API содержит довольно много багов. Для решения проблемы вы всегда можете обратиться в техподдержку. Как правило, у каждой социальной сети есть своя консоль для тестирования. И иногда у нее имеется функция сохранения запроса, к которому вы сможете прикрепить ссылку. Например, в Фейсбуке ответ возвращает идентификатор запроса в хедере. Его также можно прикрепить к сообщению. При работе с другими социальными сетями, уточняйте, как вы можете помочь техподдержке воспроизвести ошибку наиболее эффективно.
Совет: к сожалению, на общение с техподдержкой серьезно влияет человеческий фактор. Мы не раз сталкивались с тем, что проблема решалась только когда тикет создавался повторно и попадал к другому сотруднику.
Организация кода
Вот и добрались до самого главного. Так как нам надо было вытягивать данные, мы назвали модуль работы с социальными сетями “grabbers”. Перед вами пример базового граббера:
Как видите, код инициализируется с помощью токенов доступа, тянет из конфигов ключи приложения и вызывает метод для инициализации API клиента. Задачу уникализации ошибок от API решает базовый класс. Это позволяет нам иметь единую логику для их обработки. Если ошибка токена — помечаем аккаунт, как невалидный и просим пользователя переподключить социальную сеть. Если превышен лимит — повторяем попытку через некоторое время. Если ошибка сервера — пробуем снова через пару минут. Если какая-либо другая ошибка — логируем ее и ничего не делаем.
Дальше каждый граббер для социальной сети выглядит примерно так:
У нас есть главный метод grab_endpoit, который делает конкретный запрос и передает управление в метод с одноименным названием. Перед этим происходит нормализация параметров. Таким образом, мы можем передавать параметры для всех социальных сетей извне и в одинаковом формате. Далее вызывается метод гема социальной сети, и результат приводится к единому формату. Как видите, фактически все ключевые особенности работы с Facebook находятся в одном месте и, как правило, в одном классе. К сожалению, новая версия API Facebook все же не работает, как заявлено. Поэтому для получения изображений большого размера приходится использовать такой костыль:
Выводы
- В организации API социальных сетей используются одни и те же принципы. Поэтому работа с каждой из них имеет массу общих и минимум различных моментов.
- При работе с API социальных сетей главной задачей является написание системы классов, принимающих стандартизированные параметры и возвращение результатов в едином формате.
- Ключевые особенности работы с каждой конкретной социальной сетью должны быть собраны в одном месте.
- Не забывайте логировать все запросы к социальным сетям. Небольшое изменение API может сломать ваше приложение.
- Следите за официальными блогами для разработчиков каждой социальной сети. Как правило, в них объявляют о значительных изменениях и дают советы по миграции на новые версии.
