Где можно найти документацию по VK Streaming API?

Question

[Дмитрий Масленников]

С лета этого года ВКонтакте ужесточает лимиты на вызов методов newsfeed.search, wall.search и wall.get и предлагает использовать их новый Streaming API для интерактивного получения данных по этим методам, но нигде нет информации по использованию этого API. Кто знает где можно почитать документацию по Streaming API (в разделе для разработчиков у них пока ничего нет)?

Также интересуют данные по новым лимитам. Пока есть информация по количественному ограничению вызова метода newsfeed.search (до 100.000 запросов в сутки) с 07.06.2017. Кто-нибудь знает про другие ограничения?

Сама новость в Roadmap:
https://vk.com/dev/data_limits

Comments

[Дмитрий Масленников]

Александр + а смысл им тогда это публиковать в Roadmap? к тому же, судя описанию изменений контакт в борьбе с "огромной и бессмысленной" нагрузкой очень хочет пересадить часть сервисов на коммерческую версию этого API. а есть данные про новые частотные ограничения? если речь, про то, чтобы уменьшить частоту вызова отдельных методов в несколько раз, им это не сильно поможет. кто обходил ограничения, тот просто добавит аккаунты приложений и прокси.

[Дмитрий Масленников]

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

Answer 1

[Дмитрий Масленников]

Появилась документация по Streaming API:

https://vk.com/dev/streaming_api_docs

Но там реально жесть, в базовой версии максимальное количество запросов (правил), по которым поступают данные = 10 штук, в ответе выдается 1% от всей доступной информации (говоря русским языком не выдается практически ничего)).

Answer 2

[Flur]

Пока нигде. API существует, но приватное, а когда ожидать публичное api - неизвестно.

Comments

[Дмитрий Масленников]

а есть ли какие данные по итоговым ограничениям для методов newsfeed.search, wall.search и wall.get? в roadmap нас убеждают, что запрашивать данные для анализа через эти методы "станет невозможно", но насколько это реально "невозможно"? если речь выставить суточные ограничения до 100.000 запросов, то это одно, если 100 бесплатных запросов у поиска google - это совсем другое.

[Дмитрий Масленников]

Решил попробовать направить им петицию против движения в сторону закрытия API, кто знает, может прислушаются. Буду признателен, если поддержите мое начинание: https://www.change.org/p/%D0%B2%D0%BA%D0%BE%D0%BD%...

[Flur]

Дмитрий Масленников: К сожалению, ничего не решим и петиция ваша тоже. VK - коммерческий проект. Им абсолютно наср/ть на петиции и пожелания пользователей

[Дмитрий Масленников]

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

[Сережа Ахен]

Дмитрий Масленников: какой-то сюр. Вы голосуете петицией, действительно ценные пользователи API - рублем.

[Дмитрий Масленников]

что касается официальной информации, получил ответ от их ТП. если кратко - вся информация только по ссылке https://vk.com/dev/data_limits, ничего другого нет.

как понимаю, Streaming API еще толком и не доделан (если судить по еще одному "продукту" сим-картам VK, где они даже в официальной презентации открыто говорят: "мы не все сделали, но хорошо потестировали")))

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

в лучшем случае будет twitter с его недельным срезом по поиску и 15-минутными интервалами, в худшем - а-ля instagram, где обязательные review и 99% разработчиков никогда не получат нормальный доступ к публичному API.

[Дмитрий Масленников]

Сережа Ахен поясните, что вы имели ввиду? если то, что все дружно пересядут на платный API, то это вряд ли произойдет.

уже был подобный эксперимент с Instagram. после введения review люди не побежали к ним на поклон платить по 10.000$ за урезанный API. народ просто плюнул и пересел на Private API. Еще год назад на Гитхабе было днем с огнем не сыскать хоть какого-нибудь кода на приватном API, зато сейчас там не менее сотни активно поддерживаемых веток по этому вопросу.

[Сережа Ахен]

Дмитрий Масленников: ну не произойдет, дальше то что? Десять человек платящих 10к$ выгоднее чем миллион не платящих, не? Реализовать в привате то, за что вк хотят брать плату - ну так для мелких приложений у них итак бесплатно остается, а для крупных в продакшн выпускать что-то на приватных API, которые отвалятся в любой момент - верх глупости.

[Дмитрий Масленников]

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

смотря что выпускать. бесспорно одно - надо распределять риски и не завязывать значимый функционал на 1-2 сервисах. по мне времена kate mobile прошли. сейчас сильно поуменьшилось количество желающих посвящать пару лет на написание приложения, которое могут вырубить в один момент.

[Flur]

Десять человек платящих 10к$ выгоднее чем миллион не платящих, не?

Сережа Ахен: нет. Есть другие способы монетизации

[Сережа Ахен]

Flur: проясните (интересуюсь).

[Flur]

Сережа Ахен: Ну, например, предоставлять API для некоммерческого использования бесплатно.

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

[Сережа Ахен]

Flur: да, я понял вас, действительно другая возможность монетизации, вопросов больше не имею.

[Дмитрий Масленников]

По мне монетизация через API (если она не вводилась сразу на старте) приносит платформам намного больше вреда, чем пользы.

Множество разработчиков создают свои сервисы, приложения и проекты, завязанные на эти API, способствуют значительной популяризации платформы (из актуального, например, тот же telegram в бразилии 90% аудитории получил через несколько сторонних приложений на базе их API), а потом им просто говорят "спасибо, все свободны" или платите 5$ за 1000 запросов (hello, google))). Часть приложений вообще создается на некоммерческих условиях, а в большинстве остальных подобная экономика сделает нерентабельной даже самую успешную коммерческую модель.

В итоге останется часть ранее сделанных крупных сервисов, которые смогут найти общий язык с вендором по новым правилам (но и тут им не придется рассабляться, по практике через некоторое время их выдавят с рынка), ну и некоторая часть рекламных систем, которые интересны только узкой аудитории. Этого уже добился Facebook и чуть было не пришел к этому Twitter. В результате никому и в голову не придет создавать свой сервис на основе Graph API. А вот приложений на Telegram превеликое множество - начиная от различных вариаций мессенджеров до встраивания функционала платформы в приложениях в качестве бесплатной IM-части.

На мой взгляд куда более вменяемая коммерческая модель - органичное использование на платформе ненавязчивого платного функционала второстепенных частей (типа подарков, рейтинга вконтакте), разделение доходов разработчиков сторонних приложений (в формате app store/google play) или прямая donate-модель (ранее в whatsapp, wikipedia и т.д.)