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

Question

Предположим, есть мобильное приложение и сервер.

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

Представьте себе сценарий, который я хочу построить, следующий (упрощенный в тривиальный пример для этого обсуждения). Предположим, что пользователь вошел в Twitter для всего этого обсуждения, чтобы удалить обсуждение о oAuth.

Mobile talks to our service to show users twitter friends list. Every time the mobile app is loaded, it will show the entire friends list, and highlighting the new friends that were added within the last 2 days.

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

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

Наш первоначальный проект заставлял наш сервер выполнять всю работу с этим потоком:

1. Новый пользователь входит в систему на клиенте, дает токен доступа к серверу
2. Сервер вызывает API Twitter REST для получения первоначальных списков друзей
3. Сервер хранит идентификаторы друзей в Твиттере и показывает клиенту этот список.

Периодически (например, каждые 48 часов) сервер проверяет API REST Twitter на наличие списка друзей для каждого пользователя и сравнивает его с кэшированным списком друзей Twitter, который у нас есть, чтобы узнать, кто новичок, и выделить в мобильном приложении.

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

Проблема с этим дизайном заключается в том, что он будет работать для одного пользователя, но, поскольку ограничение скорости для вызовов без аутентификации составляет 150 в час, я достигну своего предела, как только 151 пользователь будет использовать мой сервис (который имеет фиксированный IP).

Единственное решение, которое я вижу, - это чтобы клиент выполнял работу для каждого пользователя, а затем отправлял мне список друзей, которые кэширует мой сервер. Это заботится о шаге № 2 выше. Однако для шага № 4 мне нужно будет встроить что-то в клиент для автоматического обновления друзей в Твиттере и отправки обратно на сервер.

Это очень неуклюже, когда клиент вообще участвует в этой операции со списком друзей в Твиттере.

Сначала я думал, что я сошел с ума, и публичные неаутентифицированные API, такие как получение списков друзей, не будут подвергаться ограничению скорости. Однако, согласно их документам, это так.

Я что-то упускаю из виду, или единственный способ решить эту проблему - вставить в клиент тяжелую логику?

Answer 1

С отсутствующим белым списком для тех, кто не является дедушкой или деловыми партнерами Twitter, я не думаю, что у вас есть какая-либо альтернатива, кроме как заставить ваше мобильное приложение выполнять вызовы API Twitter с телефона.

Возможность звонить по телефону с Twitter - это неплохо.Практически каждый клиент Twitter в мире делает это.Одним из преимуществ будет то, что пользователь будет аутентифицирован в Twitter, и, таким образом, вам будут доступны его полные 350 звонков в час.Имейте в виду, однако, что вам следует свести к минимуму ваши звонки, поскольку у пользователя могут быть установлены другие приложения с поддержкой Twitter на его телефонной трубке, которые поглощают ваше выделение вызовов, и наоборот.

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

http://api.twitter.com/1/friends/ids.json?screen_name=yourUsersName

Приведенный выше вызов вернетсамые последние 5000 идентификаторов друзей в порядке следования для @ yourUsersName .Если вы хотите получить больше идентификаторов друзей, чем первые 5000, вам нужно указать параметр cursor , чтобы инициировать paging .

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

Если нам нужны только идентификаторы друзей, тогда мы совершаем плату за один вызов API на 5000 идентификаторов друзей.Однако, если нам необходимо получить информацию о пользователях и для этих новых друзей, я бы позвонил users / lookup и передал список всех новых пользователей, которых мы обнаружили при синхронизации идентификаторов друзей.Вы можете запросить до 100 пользовательских объектов одновременно.

http://api.twitter.com/1/users/lookup.json?user_id=123123,5235235,456243,4534563

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

Итак, скажем, например, что у пользователя 2500 друзей и он никогда не использовал ваше приложение раньше.В этом случае она будет записывать один звонок, чтобы получить все идентификаторы друзей, и 25 звонков для получения информации ее друзей.Это не так уж плохо, чтобы приложение заполнялось данными.

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

Наконец, после того, как данные были обновлены на телефоне, можно собрать дельты для идентификаторов и пользовательских данных и отправить их на ваш сервер.

Может даже оказаться, что вашему серверному приложению вообще не придется взаимодействовать с Twitter, и это должно уменьшить ограничение на 150 пользователей, с которым вы сталкиваетесь.

Некоторые заключительные замечания:

1. Обязательно отметьте в политике конфиденциальности вашего приложения, что вы синхронизируете список друзей вашего пользователя с вашим сервером.
2. Я рекомендую указать JSON в качестве возвратаформат для всех вызовов API Twitter.Это гораздо более легкий формат документа, чем XML, и вы, как правило, будете передавать по проводам только от 1/3 до 1/2 объема данных.
3. Выберите подходящую платформу Twitter дляваше мобильное устройство и ваш язык программирования.В настоящее время доступ к Твиттеру является товаром, и нет оснований изобретать способ доступа к API Twitter.

Я ответил на аналогичный вопрос о подходе для эффективного извлечения подписчиков здесь .

Answer 2

Поскольку вы делаете запрос от имени пользователей, вы должны сделать так, чтобы эти запросы аутентифицировались как эти пользователи. Тогда запросы будут учитываться для каждого пользователя в собственном пуле 350 запросов / час.