- PVSM.RU - https://www.pvsm.ru -
Прошлой осенью я публиковал на Хабре пост Пять способов ускорить запросы API Facebook на практике [1], который оказался неплохим сборником рецептов. За это время Facebook API сильно изменился, став еще лучше. Теперь я редко встречаю задачи, с которыми я бы не смог справиться за один HTTP запрос к API. А все благодаря новым возможностям, о которых я и расскажу сейчас.
Вот какие способы были в прошлый раз:
Все запросы можно выполнить в Graph API Explorer [2], который теперь поддерживает FQL запросы.
Multi-query – это несколько запросов FQL, которые отправляются в одном Graph API запросе. Multi-query обрабатываются быстрее, чем такая же пачка FQL запросов, отправленных через Batch Request. При этом они не только могут передать ответ по нескольким объектам, но и решают одну из проблем простых FQL запросов.
Допустим вы хотите получить список пользователей, которые собираются посетить определенное мероприятие. Вы пишете FQL запрос:
SELECT name, url, pic FROM profile WHERE id IN (SELECT uid FROM event_member WHERE eid=12345678)
Но такой запрос дает вам всех пользователей, не давая информации о статусе (attending, unsure, declined, not_replied). Все хорошо, если вам нужно выводить информацию только тех, кто пойдет на мероприятие. Тогда вы просто добавляете в условие вложенного запроса AND rsvp_status = 'attending'. Но что вам делать, если на одной странице вам нужно отобразить всех пользователей, разбив их по статусам RSVP. Делать 4 FQL запроса c разными условиями и отправлять их с помощью batch?
Facebook предлагает вам составить два запроса и использовать данные одного во втором. Для нашего примера запросы будут следующими:
«query1»:«SELECT uid, rsvp_status FROM event_member WHERE eid=12345678»
«query2»:«SELECT name, url, pic FROM profile WHERE id IN (SELECT uid FROM #query1)»
Теперь за один запрос вы получите все необходимые данные, причем это будет быстрее, чем через batch.
Подробнее про Multi-query вы можете посмотреть в документации [3].
Теперь в одном batch запросе вы можете передавать разные HTTP методы: GET, POST, DELETE. Например, опубликовать новый статус и вернуть новостную ленту пользователя за один запрос. Но плюшки не в этом, а в “зависимостях”.
Изначально запросы были независимыми. Но сейчас вы можете использовать данные одного запроса в другом, при этом управлять зависимостями с помощью JSONPath [4] выражений.
Самый простой пример: получить данные 5-и друзей. Это можно сделать с помощью такого запроса:
batch=[{«method»:«GET»,«name»:«get-friends»,«relative_url»:«me/friends?limit=5»,},{«method»:«GET»,«relative_url»:"?ids={result=get-friends:$.data.*.id}"}]
Стоп! Так это же мы можем сделать и с помощью Multi-query, скажете вы. Да, пример нужно подобрать другой, чтобы показать всю мощь. А как вам этот:
batch=[{ «method»:«GET»,«name»:«one-friend»,«relative_url»:«me/friends?limit=1»,},{ «method»:«POST», «relative_url»:«me/feed», «body»:«message={result=one-friend:$.data.0.name} is my friend»}]
Мы получаем одного из друзей пользователя и используем его данные для того, чтобы опубликовать новый пост. Не нужно двух отдельных запросов.
Вы можете использовать до 50-и запросов в batch, управлять поведением запросов с помощью параметров omit_response_on_success и depends_on, а также использовать разные access_token (пользователя, страницы, приложения) в разных запросах. Документация по Batch Requests [5].
В начале года Facebook поддержал HTTP ETags [6]. Принцип их работы прост:
Использовать это желательно с теми данными, которые не меняются часто. Например, не стоит использовать ETags в запросах ленты новостей или сообщений. Но для запросов списка друзей в мобильных приложениях на медленных подключениях производительность конечно повысится.
Подробнее про ETags а также пример кода вы можете посмотреть в этом посте [7] в блоге разработчиков.
Выше я уже описал два способа, как можно получить в одном запросе данные из связанных объектов с помощью Multi-query и Batch с JSONPath. Но для Graph API запросов есть вариант проще.
Например, мы хотим вывести на станице имя пользователя, его день рождения и последние 10 фотографий. Все это мы можем сделать с помощью такого запроса:
me?fields=name,birthday,photos.limit(10).fields(id, picture)
Или мы хотим выводить комментарии к фотографии, но нам недостаточно стандартных полей, и мы хотим добавить еще день рождения комментаторов. Запрос следующий:
<photo_id>/comments?fields=from.fields(id, name, birthday)
Такие запросы вы можете составлять для всех identifiers, fields and connections. Не правда ли, намного легче и удобнее? Документация по field expansion [8].
В прошлой статье я уже писал про фильтрацию и пагинацию с помощью filter и offset. Хотя этот способ весьма полезен, но у него все же есть один большой недостаток. В каждом запросе у вас выводятся ссылки previous и next несмотря на то, существуют ли за ними данные, или нет.
Facebook предлагает новое решение: cursor-based offset paging. Вам больше не будут показывать previous и next, если больше нет данных. Если есть предыдущая/следующая страница, будут отображены ссылки before/after в запросе. Вы сэкономите “один проход”, просматривая каждую коллекцию объектов.
К сожалению, Cursor-based Pagination пока есть не для всех объектов. Но это уже вопрос времени. Следите за документацией [9] и используйте более эффективные решения.
Ну а если вы использовали все возможности для оптимизации, не забудьте посмотреть статью Оптимизируем запросы к Facebook Graph API с помощью Real-Time Updates [10].
В заключение хотел напомнить, что 1-го октября в Москве будет Facebook Developer HACK 2012. Если вы не сможете присутствовать лично, оставьте свои вопросы в комментариях. Лично у меня скопилось достаточно вопросов к инженерам Facebook.
Автор: antonsnowy
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/facebook/14769
Ссылки в тексте:
[1] Пять способов ускорить запросы API Facebook на практике: http://habrahabr.ru/post/132794/
[2] Graph API Explorer: https://developers.facebook.com/tools/explorer/
[3] документации: https://developers.facebook.com/docs/reference/fql/
[4] JSONPath: http://code.google.com/p/jsonpath/
[5] Batch Requests: https://developers.facebook.com/docs/reference/api/batch/#operations
[6] HTTP ETags: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19
[7] в этом посте: https://developers.facebook.com/blog/post/627/
[8] field expansion: https://developers.facebook.com/docs/reference/api/field_expansion/
[9] документацией: https://developers.facebook.com/docs/reference/api/pagination/
[10] Оптимизируем запросы к Facebook Graph API с помощью Real-Time Updates: http://habrahabr.ru/post/124195/
Нажмите здесь для печати.