Uso de la API Graph

La API Graph es la principal forma de introducir datos en la gráfica social y extraer información de esta. Se trata de una API basada en HTTP de nivel bajo que se utiliza para consultar datos, publicar nuevas historias, subir fotos y muchas otras tareas que se pueden requerir en una aplicación. En esta guía obtendrás información sobre cómo hacer todo esto en la API Graph.

Aspectos básicos

En Información general sobre la API Graph tratamos los aspectos básicos relacionados con la terminología y la estructura de esta API. Las siguientes secciones ofrecen información más detallada sobre las diferentes operaciones que pueden llevarse a cabo con la API.

Leer

Todos los nodos y perímetros de la API Graph pueden leerse de forma sencilla mediante una solicitud HTTP GET al extremo relevante. Por ejemplo, si quisieras recuperar información sobre el usuario actual, realizarías una solicitud HTTP GET del siguiente modo:

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

La mayoría de las llamadas a la API deben firmarse con un identificador de acceso. Para determinar qué permisos son necesarios en este identificador de acceso, consulta la referencia de la API Graph correspondiente al nodo o perímetro que desees leer. También puedes utilizar el explorador de la API Graph para generar rápidamente identificadores, con el fin de explorar las diferentes opciones de la API y familiarizarte con su funcionamiento.

El nodo /me es un extremo especial que se traduce en el objeto user_id de la persona (o el objeto page_id de la página de Facebook) cuyo identificador de acceso se va a utilizar para realizar las llamadas a la API. Si tuvieras un identificador de acceso de usuario, podrías recuperar todas las fotos de un usuario mediante la siguiente solicitud:

GET graph.facebook.com
  /me/photos

Aunque la respuesta que recibas variará en función del nodo o el perímetro que leas, en líneas generales, tendrá la siguiente forma:

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

Elegir campos

De forma predeterminada, no se devuelven todos los campos de un nodo o perímetro al realizar una consulta. Puedes elegir los campos o perímetros que quieres que se devuelvan mediante el parámetro de consulta fields. Este parámetro resulta muy útil para realizar llamadas más eficientes y rápidas a la API.

Por ejemplo, en una llamada a la API Graph en la que se use tu propio identificador de acceso de usuario (https://graph.facebook.com/me?fields=id,name,picture) solo se devolverá el identificador, el nombre y la foto de tu perfil:

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

Ordenar

Algunos conjuntos de datos pueden ordenarse cronológicamente. Por ejemplo, puedes organizar los comentarios de una foto en orden cronológico inverso utilizando la clave reverse_chronological.

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

order debe tener uno de los siguientes valores:

  • chronological
  • reverse_chronological

Buscar URL

La mayoría de los objetos pueden descubrirse por sus identificadores. Sin embargo, hay ocasiones en las que esto no resulta posible porque solo se tiene una URL.

Puedes utilizar el nodo "URL", que se incorporó en la versión 2.1, para obtener los identificadores de URL de objetos de Open Graph o buscar datos asociados a una URL del enlace de aplicación.

Para obtener más información sobre cómo buscar datos del enlace de aplicación con la API de indexación, consulta nuestra documentación de App Links.

Modificar solicitudes de API

Algunos extremos de API pueden utilizarse con parámetros adicionales que modificarán la solicitud. La naturaleza de las acciones que desencadenan estos modificadores varía, por lo que hemos documentado cada uno de ellos por separado en la referencia de las API a las que corresponden. A continuación figura una lista de modificadores comunes que pueden utilizarse con la mayoría de los extremos.

Nombre Descripción Tipo

return_ssl_resources

Se utiliza cuando debe devolverse una imagen a través de una conexión segura (HTTPS) para evitar advertencias sobre contenido mezclado en navegadores.

bool

locale

Se utiliza cuando una aplicación precisa poder recuperar contenido localizado en el idioma de una configuración regional concreta (si está disponible).

Locale

Más adelante se muestran otros modificadores de paginación e introspección.

Realizar solicitudes anidadas

La función de expansión de campos de la API Graph permite anidar varias consultas a la gráfica en una sola llamada de un modo muy eficaz. Algunos recursos, incluidos casi todos los de la API de anuncios, no pueden utilizar la expansión de campos en algunas o en todas las conexiones.

Por ejemplo, en una sola llamada puedes solicitar las primeras N fotos de los primeros K álbumes. La respuesta mantiene la jerarquía de los datos, de tal modo que los desarrolladores no tienen que entrelazar los datos en el cliente.

Es diferente de la función de solicitudes en lotes, que permite realizar varias llamadas a la API Graph sin posible relación en una sola solicitud.

Este es el formato general que adopta la expansión de campos:

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

<first-level> serían, en este caso, uno o varios campos o perímetros (separados por comas) del nodo principal. <second-level> serían uno o varios campos o perímetros (separados por comas) del nodo de primer nivel.

No existe limitación alguna con respecto a la cantidad de niveles que se pueden anidar. También puedes utilizar un argumento .limit(n) en cada campo o perímetro para restringir el número de objetos que quieres obtener.

Como resulta más fácil de entender de forma gráfica, a continuación te mostramos una consulta de ejemplo que recuperará hasta cinco álbumes que ha creado una persona y las últimas cinco publicaciones de su sección de noticias.

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

Podemos ampliarla un poco más y que, para cada objeto de álbum, recupere también las dos primeras fotos y las personas etiquetadas en cada una:

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

A continuación, podemos ampliarla de nuevo recuperando el nombre y la URL de cada foto, además de las personas que aparecen etiquetadas:

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

A continuación te mostramos un ejemplo de cómo usar la paginación basada en cursores.

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

Puedes comprobar cómo funciona la expansión de campos en los distintos nodos, perímetros y campos para devolver datos muy complejos en una sola solicitud.

Pasar resultados paginados

Cuando realizas una solicitud de API para un nodo o perímetro, normalmente no recibes todos los resultados de la solicitud en una sola respuesta. Esto se debe a que algunas respuestas podrían contener miles de objetos y, por ello, la mayoría de las respuestas se paginan de forma predeterminada.

Paginación basada en cursores

El método de paginación basada en cursores es el más eficiente y debería utilizarse en todos los casos posibles. Un cursor se refiere a una cadena de caracteres aleatoria que marca un elemento específico en una lista de datos. A menos que se elimine este elemento, el cursor siempre apuntará a la misma parte de la lista, pero dejará de ser válido si se elimina el elemento. Por lo tanto, tu aplicación no debería almacenar cursores y presuponer que seguirán siendo válidos en el futuro.

Cuando leas un perímetro que admita la paginación basada en cursores, aparecerá la siguiente respuesta 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="
  }
}

Un perímetro paginado mediante cursores admite los siguientes parámetros:

  • before: cursor que apunta al inicio de la página de datos que se ha devuelto.
  • after: cursor que apunta al final de la página de datos que se ha devuelto.
  • limit: número máximo de objetos que pueden devolverse. Debido a posibles filtros, una consulta puede devolver un número de objetos menor al máximo indicado en limit. No te guíes por el hecho de que el número de resultados sea menor al valor de limit para saber si la consulta ha llegado al final de la lista de datos. En su lugar, básate en la ausencia del parámetro next, como se explica más adelante. Por ejemplo, si estableces el valor de limit en diez objetos y se devuelven nueve resultados, es posible que haya más datos disponibles, pero que se haya eliminado un elemento debido a un filtro de privacidad. Algunos perímetros también pueden aplicar un límite máximo al valor de limit por motivos de rendimiento. En todos los casos la API devuelve los enlaces de paginación correctos.
  • next : extremo de API Graph que devolverá la página de datos siguiente. Si no se incluye, la página de datos actual será la última. Debido al funcionamiento de la paginación en cuanto a visibilidad y privacidad, es posible que haya una página vacía con un enlace de paginación "next". Deja de paginar cuando ya no aparezca el enlace "next".
  • previous : extremo de API Graph que devolverá la página de datos anterior. Si no se incluye, la página de datos actual será la primera.

No almacenes cursores. Los cursores pueden dejar de ser válidos rápidamente al añadirse o eliminarse elementos.

Paginación basada en tiempo

La paginación basada en tiempo se utiliza para navegar por datos de resultados con marcas de tiempo UNIX, que apuntan a horas específicas en una lista de datos.

Cuando utilices un extremo con paginación basada en tiempo, aparecerá la siguiente respuesta 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"
  }
}

Un perímetro paginado en función del tiempo admite los siguientes parámetros:

  • until : marca de tiempo UNIX o valor de datos strtotime que apunta al final del intervalo de datos basados en tiempo.
  • since : marca de tiempo UNIX o valor de datos strtotime que apunta al inicio del intervalo de datos basados en tiempo.
  • limit: número máximo de objetos que pueden devolverse. Debido a posibles filtros, una consulta puede devolver un número de objetos menor al máximo indicado en limit. No te guíes por el hecho de que el número de resultados sea menor al valor de limit para saber si la consulta ha llegado al final de la lista de datos. En su lugar, básate en la ausencia del parámetro next, como se explica más adelante. Por ejemplo, si estableces el valor de limit en diez objetos y se devuelven nueve resultados, es posible que haya más datos disponibles, pero que se haya eliminado un elemento debido a un filtro de privacidad. Algunos perímetros también pueden aplicar un límite máximo al valor de limit por motivos de rendimiento. En todos los casos la API devuelve los enlaces de paginación correctos.
  • next : extremo de API Graph que devolverá la página de datos siguiente.
  • previous : extremo de API Graph que devolverá la página de datos anterior.

Para obtener resultados coherentes, especifica los parámetros since y until. Se recomienda que el período de tiempo no supere los seis meses.

Paginación basada en desplazamientos

Utiliza la paginación basada en desplazamientos si no te importa la cronología y solo esperas que se devuelva un número concreto de objetos. Este tipo de paginación debe utilizarse únicamente si el perímetro no admite la paginación basada en cursores ni en tiempo.

Un perímetro paginado en función de los desplazamientos admite los siguientes parámetros:

  • offset : desplaza el inicio de cada página según el número especificado.
  • limit: número máximo de objetos que pueden devolverse. Debido a posibles filtros, una consulta puede devolver un número de objetos menor al máximo indicado en limit. No te guíes por el hecho de que el número de resultados sea menor al valor de limit para saber si la consulta ha llegado al final de la lista de datos. En su lugar, básate en la ausencia del parámetro next, como se explica más adelante. Por ejemplo, si estableces el valor de limit en diez objetos y se devuelven nueve resultados, es posible que haya más datos disponibles, pero que se haya eliminado un elemento debido a un filtro de privacidad. Algunos perímetros también pueden aplicar un límite máximo al valor de limit por motivos de rendimiento. En todos los casos la API devuelve los enlaces de paginación correctos.
  • next : extremo de API Graph que devolverá la página de datos siguiente. Si no se incluye, la página de datos actual será la última. Debido al funcionamiento de la paginación en cuanto a visibilidad y privacidad, es posible que haya una página vacía con un enlace de paginación "next". Deja de paginar cuando ya no aparezca el enlace "next".
  • previous : extremo de API Graph que devolverá la página de datos anterior. Si no se incluye, la página de datos actual será la primera.

Ten en cuenta que, si se añaden nuevos objetos a la lista de elementos que se está paginando, cambiará el contenido de todas las páginas basadas en desplazamientos.

La paginación basada en desplazamientos no es compatible con todas las llamadas a la API. Para obtener resultados coherentes, te recomendamos que pagines utilizando los enlaces "previous"/"next" que devolvemos en la respuesta.

Realizar grandes solicitudes

Algunos extremos de API Graph pueden aceptar parámetros muy grandes. Si tus solicitudes acaban teniendo un tamaño superior a un par de miles de caracteres, puede que se produzcan errores de servidor, ya que nuestros servidores rechazarán las solicitudes GET demasiado grandes.

A modo de práctica recomendada, en el caso de solicitudes de gran volumen, utiliza una solicitud POST en lugar de GET y añade un parámetro method=GET. De este modo, la solicitud POST se considerará una solicitud GET.

Realizar varias solicitudes

Los objetivos de la versión estándar de la API Graph son obtener datos para un objeto individual y examinar las conexiones entre objetos con facilidad. También incluye una función limitada que permite recuperar datos para varios objetos a la vez.

Si tu aplicación necesita acceder a volúmenes considerables de datos al mismo tiempo o necesitas realizar cambios en varios objetos a la vez, a menudo resulta más eficiente agrupar por lotes las consultas que realizar varias solicitudes HTTP por separado.

Para hacerlo posible, la API Graph admite una serie de funciones, como la búsqueda de varios identificadores y el procesamiento por lotes. Aunque las solicitudes en lotes se explican en una guía distinta, a continuación encontrarás más información sobre la búsqueda de varios identificadores.

Solicitudes de lectura de varios identificadores

Puedes realizar una sola solicitud GET que recupere varios nodos utilizando el extremo ?ids con los identificadores de objeto de dichos nodos. Por ejemplo, para buscar la página de Facebook para desarrolladores y el usuario de la sesión actual en una sola solicitud, podrías utilizar la siguiente llamada a la API Graph:

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

Esta llamada es equivalente a las siguientes solicitudes individuales de API:

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

Los datos devueltos tendrán un aspecto similar a este:

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

Esta opción puede funcionar también con perímetros, siempre que todos los identificadores solicitados tengan el perímetro solicitado. Por ejemplo:

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

Esta llamada es equivalente a las siguientes solicitudes individuales de API:

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

Los datos devueltos tendrán un aspecto similar a este:

{
  "{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
    ]
  }, 
}

Ten en cuenta que, aunque la limitación y el filtrado y la expansión de campos funcionarán con las búsquedas de varios identificadores, obtendrás un error si uno de los objetos no tiene alguno de los campos solicitados. Por ejemplo, si buscas una página y un usuario con este método y, a continuación, filtras por fields=id,picture,gender, la solicitud dará error porque las páginas no tienen un campo gender.

Introspección

La API Graph admite la introspección de nodos, lo que permite ver todos los perímetros de un nodo sin conocer antes el tipo. Para obtener esta información, añade metadata=1 a la solicitud de API Graph:

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

La respuesta JSON incluirá una propiedad metadata que enumera todos los perímetros compatibles del nodo en cuestión:

{
   "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"
   }
}

Publicar

La mayoría de los nodos de la API Graph tienen perímetros que pueden ser objetivos de publicación, como /{user-id}/feed o /{album-id}/photos. Todas las publicaciones de la API Graph se realizan mediante una solicitud HTTP POST al perímetro correspondiente, incluyendo los parámetros necesarios. Por ejemplo, para realizar una publicación en nombre de una persona, debe realizarse una solicitud HTTP POST del siguiente modo:

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

Todas las llamadas de publicación deben firmarse con un identificador de acceso. Para determinar qué permisos resultan necesarios en este identificador de acceso, consulta la referencia de la API Graph correspondiente al nodo en el que quieres publicar.

Son muchos los perímetros que pueden ser objetivos de publicación. Tienes los detalles en el documento de referencia de cada nodo.

La guía Escenarios comunes de uso de la API Graph contiene información adicional sobre algunos escenarios comunes de publicación.

Realizar varias solicitudes

Puedes encadenar llamadas de publicación a llamadas de lectura mediante solicitudes en lotes. Para obtener más información, consulta Realización de varias solicitudes a la API.

Lectura después de escritura

Muchos perímetros admiten la lectura después de escritura. Consulta la documentación de referencia de cada extremo para comprobar que sea compatible con la lectura después de escritura y conocer qué campos están disponibles.

Actualizar

Todas las actualizaciones de la API Graph se realizan mediante una solicitud HTTP POST al nodo correspondiente, incluyendo los parámetros actualizados necesarios, tal y como se muestra a continuación:

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

Todas las llamadas de actualización deben firmarse mediante un identificador de acceso con los mismos permisos que se precisan para publicar en dicho extremo, conforme a lo que establece la referencia de la API Graph sobre el nodo específico que desea actualizarse.

Lectura después de escritura

Muchos perímetros admiten la lectura después de escritura. Consulta la documentación de referencia de cada extremo para comprobar que sea compatible con la lectura después de escritura y conocer qué campos están disponibles.

Eliminar

Elimina nodos desde la gráfica enviándoles solicitudes HTTP DELETE:

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

Por lo general, una aplicación solo puede eliminar contenido que ella misma ha creado. Consulta la guía de referencia del nodo o perímetro para obtener más información.

Si deseas admitir clientes que no son compatibles con todos los métodos HTTP, también puedes enviar una solicitud POST a un extremo con el argumento adicional method=delete para anular el método HTTP. Por ejemplo, para eliminar un comentario, envía la siguiente solicitud:

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

Lectura después de escritura

Para crear y actualizar extremos, la API Graph puede leer inmediatamente un objeto publicado o actualizado correctamente y devolver los campos compatibles con el correspondiente extremo de lectura.

Para usar esta función, incluye un parámetro fields en tu solicitud y enumera los campos que quieres que se devuelvan. Por ejemplo, para publicar el mensaje "Hola" en la sección de noticias de un usuario, puedes hacer la siguiente solicitud:

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

Esto devolvería los campos especificados como una respuesta con formato JSON de la siguiente manera:

{
  "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",
}

Consulta la documentación de referencia de cada extremo para comprobar que sea compatible con la lectura después de escritura y conocer qué campos están disponibles.

Errores

Si ocurre un error de lectura por cualquier motivo (por ejemplo, solicitar un campo que no existe), la API Graph responderá con una respuesta de error estándar. Además, la respuesta incluirá una propiedad original_response, cuyo valor será lo que el extremo devuelve normalmente cuando se hace de manera correcta.

Por ejemplo, esta solicitud contiene un campo no válido:

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

Esta sería la respuesta:

{
  "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"
    }
  }
}

Puedes realizar búsquedas en numerosos objetos públicos de la gráfica social mediante el extremo /search. La sintaxis de las búsquedas es la siguiente:

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

Para todas las consultas de búsqueda de API Graph, debe incluirse un identificador de acceso en la solicitud. Para realizar una búsqueda, necesitas un identificador de acceso de usuario.

Tipos de búsquedas disponibles

Admitimos búsquedas de los siguientes tipos:

Tipo Descripción Valor "q"

user

Busca a una persona (si esta permite que se busque su nombre).

Nombre

page

Busca una página.

Nombre

event

Busca un evento.

Nombre

group

Busca un grupo.

Nombre

place

Busca un lugar. Para acotar la búsqueda a un lugar o una distancia en concreto, añade el parámetro center (con la latitud y la longitud correspondientes) y un parámetro distance (en metros) opcional.

Nombre

placetopic

Devuelve una lista de posibles temas de página de lugar y sus identificadores. Utilízalo con el parámetro topic_filter=all para obtener la lista completa.

Ninguno

ad_*

Recopila diferentes opciones de búsqueda que pueden utilizarse para encontrar opciones de segmentación.

Consulta Opciones de segmentación.

Ejemplo:

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

Gestionar errores

Las solicitudes realizadas a nuestras API pueden generar varias respuestas de error. En el siguiente tema se describen los métodos de recuperación y se proporciona una lista de valores de error con una guía del método de recuperación más común.

Recibir códigos de error

A continuación figura una respuesta de error común como resultado de una solicitud fallida de 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: una descripción del error en lenguaje natural.
  • code: un código de error. Más adelante se indican valores comunes y métodos de recuperación habituales.
  • error_subcode: información adicional acerca del error. Más adelante se indican valores comunes.
  • error_user_msg: el mensaje que se muestra al usuario. El idioma del mensaje se basa en la configuración regional de la solicitud de API.
  • error_user_title: el título del cuadro de diálogo, si se muestra. El idioma del mensaje se basa en la configuración regional de la solicitud de API.
  • fbtrace_id: identificador de soporte interno. Cuando informes de un error relacionado con una llamada a la API Graph, incluye fbtrace_id para ayudarnos a buscar datos de registro a efectos de depuración.

Códigos de error

Código o tipo Nombre Qué hacer

OAuthException

Si no hay ningún subcódigo, significa que el identificador de estado de inicio de sesión o de acceso ha caducado, se ha revocado o no es válido por algún otro motivo. Obtén un nuevo identificador de acceso.

Si hay un subcódigo, consúltalo.

102

Sesión de API

Si no hay ningún subcódigo, significa que el identificador de estado de inicio de sesión o de acceso ha caducado, se ha revocado o no es válido por algún otro motivo. Obtén un nuevo identificador de acceso.

Si hay un subcódigo, consúltalo.

1

API desconocida

Posible problema temporal por inactividad. Reintenta la operación tras la espera. Si vuelve a producirse, comprueba que estás solicitando una API existente.

2

Servicio de API

Problema temporal por inactividad. Reintenta la operación tras la espera.

4

Demasiadas llamadas a la API

Problema temporal por restricción. Reintenta la operación tras la espera o examina el volumen de solicitudes de la API.

17

Demasiadas llamadas de usuario a la API

Problema temporal por restricción. Reintenta la operación tras la espera o examina el volumen de solicitudes de la API.

10

Permiso de API denegado

No se ha concedido un permiso o se ha eliminado. Gestiona los permisos que falten.

190

El identificador de acceso ha caducado

Obtén un nuevo identificador de acceso.

200-299

Permiso de API (varios valores en función del permiso)

No se ha concedido un permiso o se ha eliminado. Gestiona los permisos que falten.

341

Límite de aplicación alcanzado

Problema temporal por inactividad o restricción. Reintenta la operación tras la espera o examina el volumen de solicitudes de la API.

368

Bloqueado temporalmente por incumplimiento de las políticas

Reintenta la operación tras la espera.

506

Publicación duplicada

No se pueden realizar publicaciones duplicadas de forma consecutiva. Cambia el contenido de la publicación e inténtalo de nuevo.

1609005

Error de publicación de enlace

Ha habido un problema al extraer los datos del enlace proporcionado. Comprueba la URL e inténtalo de nuevo.

Subcódigos de error de autenticación

Código Nombre Qué hacer

458

Aplicación no instalada

El usuario no ha iniciado sesión en tu aplicación. Vuelve a autenticarlo.

459

Usuario marcado

El usuario debe iniciar sesión en https://www.facebook.com o https://m.facebook.com para corregir un problema.

460

Se ha cambiado la contraseña

En iOS 6 y versiones posteriores, si la persona ha iniciado sesión utilizando el proceso integrado en el SO, se la debería redirigir a la configuración del SO de Facebook del dispositivo para actualizar su contraseña. De lo contrario, deberá iniciar sesión de nuevo en la aplicación.

463

Caducado

Identificador de acceso o estado de inicio de sesión caducado, revocado o no válido por otros motivos. Gestiona los identificadores de acceso caducados.

464

Usuario no confirmado

El usuario debe iniciar sesión en https://www.facebook.com o https://m.facebook.com para corregir un problema.

467

Identificador de acceso no válido

El identificador de acceso ha caducado, se ha revocado o no es válido por otros motivos. Gestiona los identificadores de acceso caducados.

Parámetros complejos

La mayoría de los tipos de parámetros son directamente primitivos, como string e int, pero también hay tipos list y object, que se pueden especificar en la solicitud.

El tipo list se especifica en sintaxis JSON, por ejemplo: ["firstitem", "seconditem", "thirditem"]

El tipo object también se especifica en sintaxis JSON, por ejemplo: {"firstkey": "firstvalue", "secondKey": 123}

Depurar solicitudes de API

Modo de depuración de la API Graph

Si está habilitado el modo de depuración, la respuesta de la API Graph puede contener campos adicionales que expliquen posibles problemas con la solicitud.

Para habilitar el modo de depuración, utiliza el parámetro de cadena de consulta debug. Por ejemplo:

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

Si no se ha concedido el permiso user_friends, la respuesta será la siguiente:

{
  "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"
      }
    ]
  }
}

Para el valor del parámetro debug, puede especificarse "all" o un nivel de gravedad mínimo solicitado que se corresponda con el objeto type del mensaje:

Valor del parámetro "debug" Qué se devolverá

all

Todos los mensajes de depuración disponibles

info

Mensajes de depuración con los tipos info y warning

warning

Solo mensajes de depuración con el tipo warning

La información de depuración, cuando está disponible, se devuelve en forma de objeto JSON con la clave __debug__ de la matriz messages. Cada elemento de esta matriz es un objeto JSON que contiene los siguientes campos:

Campo Tipo de datos Descripción

message

Cadena

El mensaje

type

Cadena

La gravedad del mensaje

link

Cadena

Opcional. Una URL que apunta a información relacionada.

El modo de depuración también se puede utilizar con el explorador de la API Graph.

Determinar la versión que utilizan las solicitudes de API

Al desarrollar una aplicación y realizar solicitudes de API Graph, puede ser útil saber qué versión de la API enviará una respuesta. Por ejemplo, si realizas llamadas sin especificar una versión, puede que recibas respuesta de una versión de la API que no conoces.

La API Graph proporciona un encabezado de solicitud facebook-api-version con todas las respuestas, que indica la versión exacta de la API que ha generado la respuesta. Por ejemplo, una llamada a la API Graph que genere una solicitud con la versión 2.0 tendrá el siguiente encabezado HTTP:

facebook-api-version:v2.0

Este encabezado facebook-api-version te permite determinar si las llamadas a la API se devuelven desde la versión que esperas.

Información de depuración para notificar errores

Si necesitas informar de un error de la API Graph, hay otros encabezados de solicitud que debes enviar con tu informe de error para ayudarnos a localizar y reproducir el problema. Estos encabezados son X-FB-Debug, x-fb-rev y X-FB-Trace-ID.