Комментарии 27
Спасибо, очень полезный сборник советов.
$batched_request .= ..
json_decode выучили, а json_encode — нетp.s. крик души, просто работаю на проекте, где индусы так же (склейкой частей строк) формируют многокилометровый json
я к тому что
гораздо нагляднее и безопаснее
-
- $batch = array(
- array(
- 'method' => 'POST',
- 'relative_url' => 'me/feed',
- 'body' => 'message=Скоро новый пост&link=http://habrahabr.ru/',
- ),
- array(
- 'method' => 'GET',
- 'name' => 'get-post',
- 'relative_url' => 'me/feed?limit=1',
- ),
- );
- $batched_request = json_encode($batch);
-
гораздо нагляднее и безопаснее
Думал, включать ли примеры кода на PHP (не мой язык программирования), в итоге включил, проверив что примеры работают. Про json_encode посмотрю, хотя я даже выше комментарием название функции напутал. Когда не используешь постоянно язык — пишешь с примеров кода в книжках и мануалах. А книги у меня старые, им лет 5.
Ну так пишите примеры на рабочем языке!
Это VBA и программирование для MS Office. Там просто не нужно решать такие задачи, хотя отправлять запросы можно и из слайдшоу презентации:
Sub Twttr()
On Error Resume Next
Dim objSvrHTTP As ServerXMLHTTP
Dim strT As String
Dim strResponce As String
Dim curSlide As Long
Set objSvrHTTP = New ServerXMLHTTP
objSvrHTTP.Open «GET», «search.twitter.com/search.json?q=from%3Aantonsnowy+%23habr»
objSvrHTTP.setRequestHeader «Accept», «application/xml»
objSvrHTTP.setRequestHeader «Content-Type», «application/xml»
objSvrHTTP.Send strT
If Err = 0 Then
strResponse = objSvrHTTP.responseText
Else
MsgBox «Internet connection not estableshed: » & Err.Description & "", 64, «Additt !»
End If
curSlide = ActivePresentation.SlideShowWindow.View.CurrentShowPosition
ActivePresentation.Slides(curSlide).Shapes(1).TextFrame.TextRange.text = strResponse
Использую fql через PHP SDK. Что бы использовать больше одной таблицы используйте fql multiquery.
Единственная проблема, с которой столкнулся в SDK: то ли access_token долго не живет, то ли где-то я ошибся в коде, но время от времени запросы просто не проходят, скрипт возвращает ошибку и умирает. Что бы получить данные — достаточно обновить страницу. Может знает кто-нибудь в чем дело?
Единственная проблема, с которой столкнулся в SDK: то ли access_token долго не живет, то ли где-то я ошибся в коде, но время от времени запросы просто не проходят, скрипт возвращает ошибку и умирает. Что бы получить данные — достаточно обновить страницу. Может знает кто-нибудь в чем дело?
Запросите разрешение offline_access и токен не будет устаревать.
Для создания POST запроса не обязательно использовать cURL. Можно и вот так:
function post($url, array $data)
{
$options = array(
'http' => array(
'method' => 'POST',
'header' => "Content-type: application/x-www-form-urlencoded\r\n",
'content' => http_build_query($data),
),
);
$context = stream_context_create($options);
return file_get_contents($url, false, $context);
}
Почему бы не делать максимум на клиентской стороне?
Последний проект как раз был приложением для FB. Создаешь пати, приглашаешь 4 друга, они подтверждают, получаешь код-приглашения, идешь пить бесплатный коктейль. Уже закончив и сдав проект, осознал что некоторые действия выполнялись долго, от 5 до 10 секунд, это все было связанно с запросами к FB API.
Одно из действия, создание вечеринки
1. сверял пользователя (1 запрос)
2. сверял выбранных друзей (форма выбора друзей кастомная) (1 запрос)
3. отправка выбранным друзьям на стену сообщения о приглашении на вечеринку (4 запрос)
4. отправка сообщения на свою стену о созданном приглашении (1 запрос)
может еще какие запросы, не помню… но вот эти 6-7 запросов в купе (в частности 2-й пункт, там бывало и 300-400 друзей) занимает приличное кол-во секунд.
Тек вот к чему я клоню, нужно кешировать все возможные запросы. Например у меня в примере: при выводе списка друзей закешируй я этот список, он бы мог использоваться при обработки запроса (чтобы выбранные друзья ID, были на самом деле его друзьями, а не подставленными IDшниками)
как-то так.
Одно из действия, создание вечеринки
1. сверял пользователя (1 запрос)
2. сверял выбранных друзей (форма выбора друзей кастомная) (1 запрос)
3. отправка выбранным друзьям на стену сообщения о приглашении на вечеринку (4 запрос)
4. отправка сообщения на свою стену о созданном приглашении (1 запрос)
может еще какие запросы, не помню… но вот эти 6-7 запросов в купе (в частности 2-й пункт, там бывало и 300-400 друзей) занимает приличное кол-во секунд.
Тек вот к чему я клоню, нужно кешировать все возможные запросы. Например у меня в примере: при выводе списка друзей закешируй я этот список, он бы мог использоваться при обработки запроса (чтобы выбранные друзья ID, были на самом деле его друзьями, а не подставленными IDшниками)
как-то так.
Про Batch вообще не знал, к сожалению маловато статей на тему FB API, обязательно пишите еще :)
Спасибо!
Спасибо!
Спасибо! Буду писать на новые темы.
Кстати, это уже не первая моя статья про особенности API Facebook. Например, на Хабре публиковал Оптимизируем запросы к Facebook Graph API с помощью Real-Time Updates и другие.
Кстати, это уже не первая моя статья про особенности API Facebook. Например, на Хабре публиковал Оптимизируем запросы к Facebook Graph API с помощью Real-Time Updates и другие.
Batch штука хорошая, но стоит иметь ввиду, что фейсбук считает каждый запрос внутри батча за отдельный!
Т.е. если вы пошлете 10 батчей, по 20 запросов в каждом (кстати, 20 это вродебы ограничение на количество запросов внутри одного батча), то суммарно вы получите 200 Api Calls.
Это следует учитывать при очень интенсивной работе с Facebook — ибо можно легко нарваться на превышение лимита запросов, и, как следствие, получасовой-часовой бан на любые запросы вообще, в т.ч. и авторизацию пользователей.
По личным ощущениям, лимит этот стоит держать на уровне 3.500-4.000 запросов в 30 минут, или не выше 2х запросов в секунду.
Т.е. если вы пошлете 10 батчей, по 20 запросов в каждом (кстати, 20 это вродебы ограничение на количество запросов внутри одного батча), то суммарно вы получите 200 Api Calls.
Это следует учитывать при очень интенсивной работе с Facebook — ибо можно легко нарваться на превышение лимита запросов, и, как следствие, получасовой-часовой бан на любые запросы вообще, в т.ч. и авторизацию пользователей.
По личным ощущениям, лимит этот стоит держать на уровне 3.500-4.000 запросов в 30 минут, или не выше 2х запросов в секунду.
Лучше запросы к Facebook API делать на клиенте — есть метод FB.api в JavaScript SDK, который умеет и FQL и Graph и batched requests.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять способов ускорить запросы API Facebook на практике