Использование API Graph

API Graph — это основной инструмент для загрузки и получения данных из социального графа Facebook. Он представляет собой низкоуровневый API на основе HTTP, с помощью которого можно запрашивать данные, создавать публикации, загружать фото и выполнять множество других задач, необходимых для приложения. В этом руководстве описано, как все это делать с помощью API Graph.

Основы

Структура и основные термины, связанные с API Graph, представлены в обзоре API Graph. В этом руководстве мы расскажем, как выполнять различные операции с помощью API.

Чтение

Все узлы и границы в API Graph можно считать, отправив обычный HTTP-запрос GET в нужный эндпойнт. Например, чтобы извлечь данные о текущем пользователе, необходимо отправить следующий HTTP-запрос GET:

GET /v2.5/me HTTP/1.1
Host: graph.facebook.com

Большинство вызовов API необходимо подписывать маркером доступа. Чтобы определить, какими разрешениями должен обладать маркер доступа, ознакомьтесь со справкой по API Graph для узла или границы, которые вы хотите считать. Кроме того, можно быстро сгенерировать маркеры с помощью Graph API Explorer, чтобы опробовать данный API и изучить принципы его работы.

Узел /me — это специальный эндпойнт, который транслирует user_id человека (или page_id Страницы Facebook), чей маркер доступа используется для совершения вызовов API. При наличии маркера доступа можно извлечь все фото пользователя с помощью следующего запроса:

GET graph.facebook.com
  /me/photos

Полученный отклик будет зависеть от выбранного узла или границы, однако в целом он будет выглядеть так:

{
   "fieldname": {field-value},
   ....
}

Выбор полей

По умолчанию ответ на запрос содержит не все поля узла или границы. Чтобы выбрать поля (или границы), которые будут добавлены в ответ, включите в запрос параметр fields. Благодаря этому вызовы API станут более эффективными и будут выполняться быстрее.

Например, следующий вызов API Graph, использующий ваш собственный маркер доступа пользователя https://graph.facebook.com/me?fields=id,name,picture возвратит только ID, имя и фото в вашем профиле:

GET graph.facebook.com/me?fields=id,name,picture

Сортировка

Некоторые наборы данных можно упорядочить по времени (в хронологическом порядке). Например, с помощью ключа reverse_chronological можно отобразить комментарии к фото в обратном хронологическом порядке:

GET graph.facebook.com
  /{photo-id}?
    fields=comments.order(reverse_chronological)

Поле order должно иметь одно из следующих значений:

  • chronological
  • reverse_chronological

Поиск по URL

Большинство объектов можно найти по ID, но иногда это невозможно, поскольку все, что у вас есть для идентификации объекта — это URL.

С помощью узла URL, впервые представленного в версии 2.1, можно вернуть ID URL объектов Open Graph или найти данные, связанные с URL ссылки на приложение.

Подробнее о поиске ссылок на приложения с помощью API Index см. в нашей статье, посвященной ссылкам на приложения.

Изменение запросов API

Для некоторых эндпойнтов API можно задать дополнительные параметры, изменяющие запрос. Эти модификаторы бывают разных типов, поэтому информацию о каждом из них мы приводим по отдельности в справке по соответствующему API (если применимо). Ниже приведен список самых распространенных модификаторов, которые можно использовать с большинством эндпойнтов.

Название Описание Тип

return_ssl_resources

Используется в запросе изображения по безопасному соединению (HTTPS). Предотвращает появление в браузерах предупреждений о смешанных материалах.

bool

locale

Позволяет приложению извлекать локализованные материалы на языке того или иного локаля (если он доступен).

Locale

Ниже представлены другие модификаторы для пейджинации и для самоанализа.

Создание вложенных запросов

Функция расширения поля API Graph позволяет вложить в один вызов несколько запросов API Graph. Некоторые ресурсы (например, большинство ресурсов API Ads) не могут использовать расширения полей на некоторых или на всех подключениях.

Например, в одном вызове можно запросить первые N фото первых K альбомов. В полученном отклике сохраняется иерархия данных, и разработчикам не приходится упорядочивать их на клиенте.

Пакетные запросы — это другая функция, позволяющая объединять в одном запросе несколько вызовов API Graph, даже если они не связаны между собой.

Формат расширения поля:

GET graph.facebook.com
  /{node-id}?
    fields=<first-level>{<second-level>}

<first-level> в этом случае представляет собой одно или несколько полей (с разделителями-запятыми) или границ из родительского узла.. <second-level> представляет собой одно или несколько разделенных запятыми полей или границ из узла первого уровня.

Количество уровней вложения не ограничено. В каждое поле или границу также можно добавить аргумент .limit(n), чтобы ограничить количество получаемых объектов.

Чтобы вам было проще понять эти принципы, рассмотрим пример. Ниже представлен запрос, который извлекает до пяти альбомов, созданных человеком, и последние пять публикаций в ленте этого человека.

GET graph.facebook.com
  /me?
    fields=albums.limit(5),posts.limit(5)

Затем можно расширить запрос: для каждого объекта альбома извлечь первые два фото и данные о людях, которые отмечены на этих фото.

GET graph.facebook.com
  /me?
    fields=albums.limit(5){name, photos.limit(2)},posts.limit(5)

Еще раз расширим запрос: извлечем имя каждого фото, URL-адрес изображения и данные об отмеченных людях.

GET graph.facebook.com
  /me?
    fields=albums.limit(5){name, photos.limit(2){name, picture, tags.limit(2)}},posts.limit(5)

Рассмотрим пример пейджинации по положению курсора:

GET graph.facebook.com
  /me?fields=albums.limit(5){name,photos.limit(2).after(MTAyMTE1OTQwNDc2MDAxNDkZD){name,picture,tags.limit(2)}},posts.limit(5)

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

Отображение результатов с разбивкой по страницам

Как правило, при отправке запроса API на узел или границу вы не сможете получить все результаты этого запроса в одном отклике, поскольку возвращенных объектов может быть несколько тысяч. Поэтому в большинстве откликов используется пейджинация по умолчанию.

Пейджинация по положению курсора

Пейджинация по положению курсора — это самый эффективный способ пейджинации, поэтому старайтесь по возможности использовать именно его. Курсор указывает на случайным образом выбранную строку символов, которой отмечен определенный элемент в списке данных. Если этот элемент не удален, курсор всегда будет указывать на одну и ту же часть списка. При удалении элемента курсор становится недействительным. Поэтому ваше приложение не должно сохранять старые курсоры или предполагать, что они будут действительны в будущем.

При чтении границы, поддерживающей пейджинацию по положению курсора, вы получите следующий отклик JSON:

{
  "data": [
     ... Endpoint data is here
  ],
  "paging": {
    "cursors": {
      "after": "MTAxNTExOTQ1MjAwNzI5NDE=",
      "before": "NDMyNzQyODI3OTQw"
    },
    "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw"
    "next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI5NDE="
  }
}

Граница с пейджинацией по положению курсора поддерживает следующие параметры.

  • before : курсор, указывающий на начало возвращенной страницы данных.
  • after : курсор, указывающий на конец возвращенной страницы данных.
  • limit : Это максимальное количество объектов, которое может вернуть запрос. Из-за фильтрации их может быть меньше, чем указано в параметре limit. Это не значит, что запрос дошел до конца списка данных. В этом случае вам нужно ориентироваться не на параметр limit, а на отсутствие параметра next, о котором рассказано ниже. Например, если вы задали для параметра limit значение 10 и запрос вернул 9 результатов, возможно, что существует и десятый доступный объект, но он отфильтрован по уровню конфиденциальности. Для некоторых границ значение параметра limit совпадает с максимально допустимым значением. Это необходимо для повышения производительности. Во всех случаях API возвращает ссылки на правильную пейджинацию.
  • next : эндпойнт API Graph, который возвращает следующую страницу данных. Если не включено, это последняя страница с данными. Поскольку на пейджинацию влияют настройки видимости и конфиденциальности, страница может быть пустой и содержать только ссылку на пейджинацию next. Если ссылка next отсутствует, просмотр страниц следует прекратить.
  • previous : эндпойнт API Graph, который возвращает предыдущую страницу данных. Если этот параметр не входит в отклик, это значит, что возвращена первая страница данных.

Не храните курсоры. Курсоры могут быстро стать недействительными при добавлении или удалении элементов.

Пейджинация по времени

Пейджинация по времени предназначена для навигации по результатам с помощью меток времени Unix, указывающих на определенный момент времени в списке данных.

При обращении к эндпойнту, который использует пейджинацию по времени, вы получите следующий отклик JSON:

{
  "data": [
     ... Endpoint data is here
  ],
  "paging": {
    "previous": "https://graph.facebook.com/me/feed?limit=25&since=1364849754",
    "next": "https://graph.facebook.com/me/feed?limit=25&until=1364587774"
  }
}

Граница с пейджинацией по времени поддерживает следующие параметры.

  • until : метка времени Unix или значение данных strtotime, указывающее на конец диапазона основанных на времени данных.
  • since : метка времени Unix или значение данных strtotime, указывающее на начало диапазона основанных на времени данных.
  • limit : Это максимальное количество объектов, которое может вернуть запрос. Из-за фильтрации их может быть меньше, чем указано в параметре limit. Это не значит, что запрос дошел до конца списка данных. В этом случае вам нужно ориентироваться не на параметр limit, а на отсутствие параметра next, о котором рассказано ниже. Например, если вы задали для параметра limit значение 10 и запрос вернул 9 результатов, возможно, что существует и десятый доступный объект, но он отфильтрован по уровню конфиденциальности. Для некоторых границ значение параметра limit совпадает с максимально допустимым значением. Это необходимо для повышения производительности. Во всех случаях API возвращает ссылки на правильную пейджинацию.
  • next : эндпойнт API Graph, который возвращает следующую страницу данных.
  • previous : эндпойнт API Graph, который возвращает предыдущую страницу данных.

Для получения стабильных результатов укажите параметры since и until. Кроме того, разница во времени не должна превышать 6 месяцев.

Пейджинация по сдвигу

Пейджинацию по сдвигу можно использовать, если хронология не важна и нужно просто получить определенное количество объектов. Используйте этот вариант только в том случае, если граница не поддерживает пейджинацию по положению курсора или по времени.

Граница с пейджинацией по сдвигу поддерживает следующие параметры.

  • offset : сдвиг начала каждой страницы на указанное количество единиц.
  • limit : Это максимальное количество объектов, которое может вернуть запрос. Из-за фильтрации их может быть меньше, чем указано в параметре limit. Это не значит, что запрос дошел до конца списка данных. В этом случае вам нужно ориентироваться не на параметр limit, а на отсутствие параметра next, о котором рассказано ниже. Например, если вы задали для параметра limit значение 10 и запрос вернул 9 результатов, возможно, что существует и десятый доступный объект, но он отфильтрован по уровню конфиденциальности. Для некоторых границ значение параметра limit совпадает с максимально допустимым значением. Это необходимо для повышения производительности. Во всех случаях API возвращает ссылки на правильную пейджинацию.
  • next : эндпойнт API Graph, который возвращает следующую страницу данных. Если не включено, это последняя страница с данными. Поскольку на пейджинацию влияют настройки видимости и конфиденциальности, страница может быть пустой и содержать только ссылку на пейджинацию next. Если ссылка next отсутствует, просмотр страниц следует прекратить.
  • previous : эндпойнт API Graph, который возвращает предыдущую страницу данных. Если этот параметр не входит в отклик, это значит, что возвращена первая страница данных.

Обратите внимание, что при добавлении новых объектов в список объектов, разбитый на страницы, содержимое каждой из этих страниц изменяется.

Некоторые вызовы API не поддерживают пейджинацию на основе сдвига. Чтобы получить согласованные результаты, рекомендуем вам просматривать страницы с помощью ссылок previous и next, возвращенных в отклике на запрос.

Создание больших запросов

Некоторые эндпойнты API Graph поддерживают очень большие параметры. Если запрос содержит больше двух тысяч символов, он может вызвать ошибку сервера, потому что наши серверы отклоняют очень большие запросы GET.

В этом случае мы рекомендуем использовать запрос POST вместо запроса GET и добавить параметр method=GET. Тогда POST будет интерпретирован так, как если бы это был запрос GET.

Создание нескольких запросов

Стандартная версия API Graph значительно упрощает процессы получения данных по отдельным объектам и просмотр границ между объектами. Помимо этого, она позволяет извлечь данные по нескольким объектам одновременно, но с некоторыми ограничениями.

Если вашему приложению необходимо получить доступ к большим объемам данных с помощью одного запроса или вам нужно внести изменения сразу в несколько объектов, возможно, будет удобнее создать один пакет со всеми запросами, вместо того чтобы отправлять HTTP-запросы по одному.

API Graph поддерживает несколько функций, которые позволяют это сделать: например, поиск по нескольким ID и пакетные запросы. О пакетных запросах рассказано в отдельном руководстве, а сведения о поиске по нескольким ID представлены ниже.

Запрос на чтение нескольких ID

Вы можете сделать один запрос GET, возвращающий несколько узлов. Для этого используйте эндпойнт ?ids с ID объекта этих узлов. Например, чтобы найти страницу разработчиков Facebook и пользователя текущего сеанса с помощью одного запроса, можно сделать следующий вызов API Graph:

GET graph.facebook.com
  /?ids=platform,me

Такой запрос равноценен следующим отдельным запросам API:

GET graph.facebook.com
  /platform
  
GET graph.facebook.com
  /me

Возвращенные данные будут выглядеть примерно так:

{
  "me": {
    "id": "1234567890"
    ... // Other fields
  }, 
  "platform": {
    "id": "19292868552"
    ... // Other fields
  }
}

По этому же принципу можно составить запрос границ, при условии что запрошенная граница имеет отношение ко всем запрошенным ID. Например:

GET graph.facebook.com
  /photos?ids={user-id-a},{user-id-b}

Такой запрос равноценен следующим отдельным запросам API:

GET graph.facebook.com
  /{user-id-a}/photos
  
GET graph.facebook.com
  /{user-id-b}/photos

Возвращенные данные будут выглядеть примерно так:

{
  "{user-id-a}": {
    "data": [
      {
        "id": "12345", 
        "picture": "{photo-url}", 
        "created_time": "2014-07-15T15:11:25+0000"
      }
      ... // More photos
    ]
  },
  "{user-id-b}": {
    "data": [
      {
        "id": "56789", 
        "picture": "{photo-url}", 
        "created_time": "2014-01-15T12:24:47+0000"
      }
      ... // More photos
    ]
  }, 
}

Обратите внимание: несмотря на то что к поиску по нескольким ID применяется фильтрация полей, расширение полей и ограничение, такой запрос завершается ошибкой, если один из объектов не содержит какое-либо из запрошенных полей. Например, если вы выполните поиск Страницы и пользователя по этому методу, а затем фильтрацию по параметру fields=id,picture,gender, запрос не будет выполнен, поскольку Страницы не содержат поля gender.

Самоанализ

API Graph поддерживает самоанализ узлов. Эта функция позволяет видеть все границы для узла, не зная заранее их тип. Чтобы получить эти данные, добавьте в запрос API Graph параметр metadata=1:

GET graph.facebook.com
  /{node-id}?
    metadata=1

Отклик JSON будет включать свойство metadata со списком всех поддерживаемых границ выбранного узла:

{
   "name": {node-name},
   "metadata": {
      "connections": {
         "feed": "http://graph.facebook.com/me/feed",
         "picture": "https://graph.facebook.com/me/picture",
         ....
      }
      "fields": [
        {
          "name": "id",
          "description": "The user's Facebook ID. No `access_token` required. `string`."
        },
        ....
      ],
      "type": "user"
   }
}

Публикация

Большинство узлов в API Graph имеют границы, которые можно опубликовать (например, /{user-id}/feed или /{album-id}/photos. Все публикации API Graph выполняются исключительно с помощью HTTP-запроса POST со всеми необходимыми параметрами, которые отправляются на соответствующую границу. Например, чтобы создать публикацию от имени человека, необходимо отправить следующий HTTP-запрос POST:

POST graph.facebook.com
  /{user-id}/feed?
    message={message}&
    access_token={access-token}

Все вызовы, активирующие публикацию, необходимо подписывать маркером доступа. Чтобы определить, какими разрешениями должен обладать этот маркер доступа, ознакомьтесь со справкой по API Graph для узла, на котором нужно создать публикацию.

Существует много границ, поддерживающих публикацию. Подробные сведения для каждого узла см. в справочной документации.

В руководстве Распространенные сценарии использования API Graph содержится дополнительная информация о некоторых сценариях публикации.

Создание нескольких запросов

Пакетные запросы позволяют объединить вызовы публикации с вызовами чтения. Подробнее см. раздел Создание пакетных запросов API.

Чтение после записи

Многие границы контекста поддерживают чтение после записи. См. справочные статьи по каждому эндпойнту, чтобы узнать, поддерживает ли он чтение после записи и какие поля доступны.

Обновление

Все обновления API Graph выполняются исключительно с помощью HTTP-запроса POST со всеми необходимыми параметрами, которые отправляются на соответствующий узел.

POST graph.facebook.com
  /{node-id}?
    {updated-field}={new-value}&
    access_token={access-token}

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

Чтение после записи

Многие границы контекста поддерживают чтение после записи. См. справочные статьи по каждому эндпойнту, чтобы узнать, поддерживает ли он чтение после записи и какие поля доступны.

Удаление

Чтобы удалить узлы из графа, необходимо отправить на них HTTP-запрос DELETE:

DELETE graph.facebook.com
  /{node-id}?
    access_token=...

Приложение может удалить только публикации, которые оно создало. Для получения подробной информации см. справочное руководство.

Для обеспечения поддержки клиентов, которые не поддерживают некоторые методы HTTP, можно отправить в эндпойнт запрос POST с дополнительным аргументом method=delete, переопределяющим метод HTTP. Например, чтобы удалить комментарий, отправьте следующий запрос:

POST graph.facebook.com
  /{comment-id}?
    method=delete

Чтение после записи

Для эндпойнтов создания и обновления API Graph может моментально считывать успешно опубликованный или обновленный объект и возвращать любые поля, поддерживаемые соответствующим эндпойнтом чтения.

Чтобы использовать эту функцию, добавьте в запрос параметр fields и перечислите поля, которые должен вернуть запрос. Например, чтобы опубликовать в ленте пользователя сообщение «Привет», вы можете сделать следующий запрос:

POST graph.facebook.com
  /126577551217199/feed?
    message=Hello&
    fields=created_time,from,id,message,permalink_url

Запрос вернет указанные поля в формате JSON, как показано здесь:

{
  "created_time": "2017-04-06T22:04:21+0000",
  "from": {
    "name": "Jay P Jeanne",
    "id": "126577551217199"
  },
  "id": "126577551217199_122842541590700",
  "message": "Hello",
  "permalink_url": "https://www.facebook.com/126577551217199/posts/122842541590700",
}

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

Ошибки

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

Например, этот запрос содержит недействительное поле:

POST graph.facebook.com
  /126577551217199/feed?
    message=Hello&
    fields=permalink_urls

Отклик будет следующим:

{
  "error": {
    "message": "(#100) Tried accessing nonexisting field (permalink_urls) on node type (Post)",
    "type": "FacebookApiException",
    "code": 100,
    "fbtrace_id": "AzMnKh6NRKY",
    "original_response": {
      "id": "126577551217199_122842541590700"
    }
  }
}

Социальный граф позволяет найти много общедоступных объектов с помощью эндпойнта /search. Синтаксис поискового запроса:

GET graph.facebook.com
  /search?
    q={your-query}&
    type={object-type}

Во все поисковые запросы API Graph необходимо добавлять маркер доступа. Чтобы выполнить поиск, вам понадобится маркер доступа пользователя.

Доступные типы поисковых запросов

Facebook поддерживает поисковые запросы следующих типов:

Тип Описание Значение

user

Поиск человека (если он разрешил поиск по своему имени).

Название

page

Поиск Страницы.

Название

event

Поиск события.

Название

group

Поиск группы.

Название

place

Поиск места. Можно уточнить условия поиска, указав определенное место и расстояние. Для этого в запрос нужно добавить параметр center (с широтой и долготой) и дополнительный параметр distance (в метрах):

Название

placetopic

Возвращает список возможных тем Страницы места и их ID. Вместе с этим параметром используется параметр topic_filter=all для получения полного списка.

Нет

ad_*

Подборка параметров поиска, которые можно использовать для поиска параметров таргетинга.

См. Параметры таргетинга.

Пример:

GET graph.facebook.com
  /search?
    q=coffee&
    type=place&
    center=37.76,-122.427&
    distance=1000

Обработка ошибок

Отклики на запрос API могут содержать сообщение о той или иной ошибке. В этом разделе вы найдете сведения об ошибках, а также их коды и ссылки на распространенные способы устранения ошибок.

Получение кодов ошибок

Это стандартный отклик с сообщением об ошибке, возникшей в результате сбоя запроса API:

{
  "error": {
    "message": "Message describing the error", 
    "type": "OAuthException", 
    "code": 190,
    "error_subcode": 460,
    "error_user_title": "A title",
    "error_user_msg": "A message",
    "fbtrace_id": "EJplcsCHuLu"
  }
}
  • message. Описание ошибки в пригодном для чтения формате.
  • code. Код ошибки. Ниже приведены распространенные значения и способы устранения ошибок.
  • error_subcode. Дополнительные сведения об ошибке. Распространенные значения приведены ниже.
  • error_user_msg. Сообщение, отображаемое для пользователя. Язык сообщения основан на локале запроса API.
  • error_user_title. Название диалога (если отображается). Язык сообщения основан на локале запроса API.
  • fbtrace_id. Внутренний идентификатор поддержки. Если вы отправляете нам сообщение об ошибке, связанной с вызовом API Graph, включите в него параметр fbtrace_id. Он поможет нам найти данные журнала для отладки.

Коды ошибок

Код или тип Название Решение

OAuthException

Если не представлен подкод, это означает, что срок действия статуса входа или маркера доступа истек либо они отозваны или недействительны. Получите новый маркер доступа.

Если подкод представлен, см. подкод.

102

Сеанс API

Если не представлен подкод, это означает, что срок действия статуса входа или маркера доступа истек либо они отозваны или недействительны. Получите новый маркер доступа.

Если подкод представлен, см. подкод.

1

API неизвестен

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

2

API Service

Временная ошибка из-за простоя. Подождите немного и возобновите работу.

4

Слишком много вызовов API

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

17

Слишком много вызовов пользователей API

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

10

Разрешение на доступ к API отменено

Разрешение либо не предоставлено, либо было удалено. Обработка отсутствующих разрешений.

190

Срок действия маркера доступа истек.

Получите новый маркер доступа.

200-299

Разрешение API (в зависимости от разрешения значений может быть несколько)

Разрешение либо не предоставлено, либо было удалено. Обработка отсутствующих разрешений.

341

Достигнут предел, заданный для приложения

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

368

Временно заблокировано из-за нарушений политик.

Подождите немного и возобновите работу.

506

Дублирование публикации

Дублированные публикации нельзя публиковать последовательно. Измените материалы публикации и попробуйте снова.

1609005

Ошибка публикации ссылки

При попытке очистки данных по указанной ссылке возникла проблема. Проверьте URL и повторите попытку.

Дополнительные коды ошибок аутентификации

Код Название Решение

458

Приложение не установлено

Пользователь не зарегистрирован в вашем приложении. Повторно авторизуйте пользователя.

459

Пользователь проверен

Чтобы решить проблему, пользователь должен войти на https://www.facebook.com или https://m.facebook.com.

460

Пароль изменен

Если на устройствах с ОС iOS 6 и более поздних версий используется процесс входа на Facebook, интегрированный с ОС, человека необходимо направить на страницу настроек Facebook в ОС на его устройстве, чтобы он обновил пароль. Если этого не сделать, человеку придется повторно войти в приложение.

463

Срок действия истек

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

464

Неподтвержденный пользователь

Чтобы решить проблему, пользователь должен войти на https://www.facebook.com или https://m.facebook.com.

467

Недопустимый маркер доступа

Маркер доступа отозван, у него истек срок действия или они стал недействителен по другой причине. Обработка маркеров доступа с истекшим сроком действия.

Комплексные параметры

Большинство параметров имеют базовые значения (например, string и int). Тем не менее, в запросах также можно использовать параметры типа list и object.

Тип list можно задать в синтаксисе JSON, например: ["firstitem", "seconditem", "thirditem"]

Тип object также можно задать в синтаксисе JSON, например: {"firstkey": "firstvalue", "secondKey": 123}

Запросы API на отладку

Режим отладки API Graph

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

Чтобы включить режим отладки, используйте строковый параметр запроса debug. Например:

GET graph.facebook.com
  /v2.3/me/friends
    access_token=...&
    debug=all

Если разрешение user_friends не предоставлено, отклик будет следующим:

{
  "data": [
  ], 
  "__debug__": {
    "messages": [
      {
        "message": "Field friends is only accessible on User object, if user_friends permission is granted by the user", 
        "type": "warning"
      }, 
      {
        "link": "https://developers.facebook.com/docs/apps/changelog#v2_0", 
        "message": "Only friends who have installed the app are returned in versions greater or equal to v2.0.", 
        "type": "info"
      }
    ]
  }
}

Для параметра debug можно задать значение all или значение минимального запрашиваемого уровня серьезности, соответствующего типу сообщения (параметр type):

Значение параметра отладки Отклик

all

Все доступные сообщения об отладке.

info

Сообщения отладки с типом info и warning.

warning

Только сообщения об отладке типа warning.

Информация об отладке (если доступна) возвращается как объект JSON под ключом __debug__ в массиве messages. Каждый элемент этого массива — это объект JSON, содержащий следующие поля:

Поле Тип данных Описание

message

Строка

Сообщение.

type

Строка

Серьезность.

link

Строка

[Необязательно] URL, указывающий на связанную информацию.

Режим отладки также можно применить к Graph API Explorer.

Определение используемой версии с помощью запросов API

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

В каждом отклике API Graph передает заголовок запроса facebook-api-version, по которому можно определить, какая версия API сгенерировала этот отклик. Например, если отклик сгенерировал API Graph v2.0, то заголовок HTTP будет следующим:

facebook-api-version:v2.0

Этот заголовок facebook-api-version позволяет определить, возвращаются ли вызовы API из версии, которую вы ожидаете.

Информация об отладке для сообщений об ошибках

Если вам понадобится сообщить об ошибке в API Graph, вы можете включить в свой отчет заголовки запросов: Эти заголовки — X-FB-Debug, x-fb-rev и X-FB-Trace-ID.