Да, к сожалению, это известный "баг" в API Facebook вот уже год. Подробнее можно прочитать ответ официального разработчика
здесь.
Если коротко, то у API Facebook больше ограничений, чем у веб-версии сайта, поэтому невозможно получить полный список шейров через АПИ, если пользователь не разрешил вам это сделать (например, он не вы и не ваш друг). Но при этом можно увидеть их на странице в веб-версии. То есть красивого решения нет, но можно конечно попытаться пропарсить все страницы и все скроллы у каждого пользователя (что является просто идиотской потерей времени и никто на это не пойдет). На месте разработчиков, я бы сделал свое приложение, которое запрашивает доступы у пользователя - вот в этом случае можно будет получить всю инфу через апи. Стоит ли оно того для раздачи пару десятков баксов на лицо? - Нет, не стоит.
На самом деле это не единственная проблема. Например, API твиттера не позволяет узнать когда именно фолловер подписался на ваш аккаунт. Этой информации просто не существует в выдаче, будь то месяц назад или сегодня.
Поэтому все эти баунти в том или ином виде просто наебалово
я не говорю о том, что выплат не будет. Они будут, но распределение будет очень приблизительным и далеким от заявленной точности.
PS: Ответ фейсбука про шейры:
Hi everybody,
I understand that there is some confusion around the /sharedposts endpoint. There are still some edge-cases that we are investigating, but I will try to explain the situation and expected behaviour.
In sort: the /sharedposts endpoint will -only- retrieve posts from users who have -also- granted your app. This means that even though a post might be public on a users' timeline, unless they have also granted your app permissions, you will not be able to retrieve that post.
For example: a user posted to a page and the post is public. This post can be retrieved with an access token. Let's assume that the user also shared this post to their own timeline. But, since the user has not granted permissions to your app, you will not be able to see this post using the /sharedposts edge on the original post (on the page). This also holds if the user shared their post publicly to his timeline.
This behaviour is by design; the API is more restrictive in returning user data than the website is. This holds for multiple endpoint and this is one of the examples where it is the case.
Furthermore, there is a slight discrepancy between the counts as used in the API and on the website. I can't provide you with more details about that, but here it is also expected that there is a difference in numbers. This difference should not be significant.
I hope the above explanation clarifies the situation a bit more.
Thanks,
Roemer
А сейчас мы обогащаем только тролля Skyrik, который на нас нападает и провоцирует конфликт, но при этом получает 5 долей за каждый комментарий в его ветке на форуме.
