2017-02-08 9 views
0

Моя цель - поддерживать «в реальном времени» (или как можно ближе) информацию о сообщениях электронной почты, отправленных группой пользователей.Что такое хорошая стратегия для опроса API-интерфейсов Microsoft Graph, чтобы я не дросселировался?

Моим идеальным решением было бы периодически запрашивать API для сообщений всеми пользователями в группе. Эта функция не реализована (пока?).

Моим вторым выбором было бы создать подписки (https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/subscription_post_subscriptions) для каждого члена группы, а затем запросить информацию о сообщении после того, как я узнаю о событии. Проблема в том, что на практике мне разрешено создавать только 20-30 одновременных подписок (Issues to use Webhook for Microsoft Graph API), чего может быть недостаточно.

Так что я застрял в опросе всех пользователей в цикле. Основная проблема с этим подходом заключается в том, что я не могу найти какую-либо информацию о том, сколько запросов «слишком много», т. Е. Меня дросселируют. Я хочу максимизировать количество запросов, чтобы свести к минимуму время, необходимое для прохождения одного цикла.

Решение, которое приходит на ум, заключается в разработке адаптивной программы, которая медленно уменьшает время между запросами до дросселирования, а затем резко добавляет некоторое время, пока не будет найден и сохранен хороший баланс. Однако это похоже на большую работу. Сейчас я работаю над предположением, что 1/секунда - это самое высокое, что я могу безопасно пройти (0,5 секунды в среднем за один раунд, затем охлаждение еще на 0,5 секунды).

Каков наилучший способ борьбы с неизвестным пределом дросселирования в целом и Microsoft Graph в частности?

Edit:

В то время как я думаю, что принятый ответ хороший ответ, он может не подходить для всех случаев. Например, если вы не хотите использовать API 365, и вы не против использования бета-функций, возможно, вы можете проверить this (дельта-токены), которые, похоже, предназначены для синхронизации в реальном времени с данными.

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

ответ

2

Пока еще в режиме предварительного просмотра, вы можете взглянуть на Outlook Streaming Notifications. Эти API-интерфейсы обеспечивают более надежную модель уведомления, чем простые веб-перехватчики. Вам все равно нужно будет установить несколько подписчиков, но я ожидаю, что вы увидите гораздо меньше латентности.

+0

Проблема в том, что я использую потоковые уведомления или регулярные подписки, мне нужно сделать другой запрос, чтобы получить информацию о сообщении (уведомление только сообщает мне что-то, что произошло, т. Е. Создавать, обновлять, удалять, это не говорит мне что-либо о самом сообщении, то есть отправителе, адресах, размере и т. д.). Насколько я могу судить, нет способа сохранить учетную запись в режиме реального времени более подробной информации, используя эту услугу, по причинам, изложенным в мой вопрос. – piisexactly3

+0

Я думаю, что вижу свою ошибку здесь. Уведомление направило бы меня в направлении сообщения, которое устранило бы мою потребность в огромных количествах запросов. Ключевым моментом является то, сколько подписчиков Office 365 API позволит в потоковом уведомлении по сравнению с Microsoft Graph. Тем не менее, спасибо за это. – piisexactly3