グラフAPIの利用

グラフAPIは、Facebookのソーシャルグラフにデータを取り込んだり、データを取り出したりするための主な方法です。データのクエリ、新しい記事の投稿、写真のアップロード、アプリで行う必要があるその他のさまざまなタスクに利用できるローレベルのHTTPベースのAPIです。このガイドでは、グラフAPIでそれらのタスクを実行する方法について説明します。

基本

グラフAPIの基本的な用語と構造については、「グラフAPI overview (グラフAPIの概要)」でご覧いただけます。次のセクションでは、APIを使って実行できるさまざまな操作について紹介します。

読み取り

グラフAPIのすべてのノードとエッジは、関連するエンドポイントにHTTP GETリクエストを行うと簡単に読み取れます。たとえば、現在の利用者に関する情報を取得する場合は、以下のようにHTTP GETリクエストを行います。

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

ほとんどのAPI呼び出しは、アクセストークンを使って署名される必要があります。このアクセストークンで必要なアクセス許可を決定するには、読み取るノードやエッジについて「グラフAPIリファレンス」でご確認ください。グラフAPIエクスプローラを使ってトークンを短時間で作成し、APIをテストしてその動作を確認することもできます。

/meノードは特別なエンドポイントで、現在アクセストークンでAPI呼び出しに使われている利用者のuser_id(またはFacebookページのpage_id)に変わります。ユーザーアクセストークンを持っている場合、以下を使って利用者のすべての写真を取得できます。

GET graph.facebook.com
  /me/photos

受け取る応答は、読み取っているノードやエッジによって異なりますが、以下のような一般的なフォームになります。

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

フィールドの選択

デフォルトでは、クエリを実行したとき、ノードやエッジのすべてのフィールドが返されるわけではありません。fieldsクエリパラメーターを使って、返すフィールド(またはエッジ)を選択できます。これは、API呼び出しをより効率的に短時間で行う場合に非常に便利です。

たとえば、自身のユーザーアクセストークンを使用した次のグラフAPI呼び出し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のみの場合もあります。

v2.1で導入されたURLノードを使えば、Open GraphオブジェクトURLのIDを返したり、App Link URLと関連付けられているデータを見つけたりできます。

詳しくは、App Linksのドキュメントで「Finding App Link data with the Index API (Index APIを使ったApp Linksデータの検索)」をご覧ください。

APIリクエストの変更

一部のAPIエンドポイントは、リクエストを変更する追加パラメーターと併用できます。これらの「修飾子」の動作はそれぞれ異なるため、適切なAPIリファレンスドキュメントで個別に説明しています。以下は、ほとんどのエンドポイントで利用できる、一般的な修飾子のリストです。

名称 説明 タイプ

return_ssl_resources

写真をセキュアな接続(HTTPS)で返し、ブラウザで矛盾したコンテンツに関する警告が表示されないようにする場合に使います。

bool

locale

アプリに、あるロケールの言語で翻訳されたコンテンツ(利用可能な場合)を取得する機能が必要な場合に使います。

Locale

ページングイントロスペクション用のその他の修飾子について、以下に示します。

ネストされたリクエストの実行

グラフAPIのフィールド拡張機能を使って、複数のグラフクエリを効率的にネストして、1回の呼び出しで実行できます。ほとんどのAds APIを含む特定のリソースでは、一部またはすべての接続において、フィールド拡張機能を利用できません。

たとえば、K個目までのアルバムにある、N枚目までの写真を、1回の呼び出しでリクエストできます。応答では、データ階層が維持されるため、クライアントと協力してデータをまとめる必要はありません。

バッチリクエストはこれとは別の機能で、関連のない可能性のある複数のグラフAPI呼び出しを、1回のリクエストで実行できます。

フィールド拡張機能を実行する一般的なフォーマットは以下のとおりです。

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

ここでの<first-level>は、親ノードからの1つ以上のフィールド(コンマ区切り)またはエッジが考えられます。 <second-level>は、最初の階層のノードからの1つ以上のフィールド(コンマ区切り)またはエッジが考えられます。

ここでネストされる階層数に制限はありません。各フィールドやエッジで.limit(n)引数を使って、取得するオブジェクト数を制限することもできます。

実際のアクションで見たほうがわかりやすいため、他の人が作成した最大5つのアルバムと、それらのフィードの最後から5つの投稿を取得するクエリの例をご紹介します。

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

その後、これを少し拡張し、各アルバムのオブジェクトに対して最初の2枚の写真と、それぞれの写真にタグ付けされている利用者を取得します。

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)

以上が、ノード、エッジ、フィールドでフィードを拡張して、非常に複雑なデータを1回のリクエストで返す仕組みです。

ページネーション結果の移動

通常、ノードやエッジにAPIリクエストを実行する際、1回の応答でそのリクエストの結果すべてを受信するわけではありません。これは、応答によっては数千のオブジェクトが含まれている場合があり、デフォルトでは大半の応答にページネーションが適用されるためです。

カーソルベースのページネーション

カーソルベースのページネーションは、最も効率的なページング方法であり、可能な限り常に使用することをおすすめします。カーソルは、データのリスト内の特定のアイテムをマークする、ランダムな文字列を参照します。このアイテムが削除されない限り、カーソルは常にリスト内の同じ位置を指します。アイテムが削除されるとこの機能は無効になります。このため、アプリではカーソルを保管したり、それらのカーソルが将来にわたって有効であると想定したりしないようにしてください。

カーソルページネーションをサポートするエッジを読み取る際、以下の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を20に設定した場合、20個のオブジェクトが検出されますが、プライバシーフィルタリング処理されるため、9個のみが表示されます。limitを40に設定しなおした場合、40個のオブジェクトが検出されますが、ここでもフィルタリング処理されるため、12個のみが返されます。検索条件に結果が表示されない場合は、ページネーションがなく、これ以上アイテムがないことを示しますが、limitを増やすとアイテムが表示される可能性があります。パフォーマンス上の理由により、一部のエッジでは、limit値が上限を超えて設定されることがあります。
  • next :データの次ページを返すGraphAPIエンドポイントです。含まれていない場合、これはデータの最終ページになります。ページネーションが可視性やプライバシーとどのように機能するかによって、ページが空になることもありますが、'next'ページングリンクは含まれています。'next'リンクが表示されない場合は、ページングを停止してください。
  • previous :データの前のページを返すグラフAPIエンドポイントです。含まれていない場合、これはデータの最初のページになります。

カーソルは保存しないでください。アイテムが追加または削除されると、カーソルはただちに無効になります。

時間ベースのページネーション

時間によるページネーションは、データのリストで特定の時間を示す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個の場合、利用できるデータがまだあるとも考えられますが、プライバシーフィルタによって項目が1つ削除されています。 パフォーマンス上の理由により、一部のエッジでは、limit値が上限を超えて設定されることがあります。すべての呼び出しで、APIから正しいページネーションリンクが返されます。
  • next :データの次ページを返すGraphAPIエンドポイントです。
  • previous :データの前のページを返すグラフAPIエンドポイントです。

一貫性のある結果を得るには、sinceパラメーターとuntilパラメーターの両方を指定します。また、時差は最大6か月とすることをおすすめします。

オフセットベースのページネーション

オフセットページネーションは、時系列についてはこだわらず、返された特定のオブジェクト数のみが必要な場合に利用できます。これは、エッジでカーソルベースや時間ベースのページネーションがサポートされていない場合にのみ、使うようにしてください。

オフセットページネーションエッジでは、以下のパラメーターがサポートされています。

  • offset :各ページの開始を指定した数だけずらします。
  • limit :返される可能性があるオブジェクトの最大数です。フィルタリング処理されるため、返されるクエリの数はlimitよりも少なくなる場合があります。データのリストの末尾に達したクエリを示す場合は、limitの値よりも小さな結果の数を使用するのではなく、下に示すように、nextがないことで示すようにしてください。たとえば、limitを10に設定し、返された結果が9個の場合、利用できるデータがまだあるとも考えられますが、プライバシーフィルタによって項目が1つ削除されています。 パフォーマンス上の理由により、一部のエッジでは、limit値が上限を超えて設定されることがあります。すべての呼び出しで、APIから正しいページネーションリンクが返されます。
  • next :データの次ページを返すGraphAPIエンドポイントです。含まれていない場合、これはデータの最終ページになります。ページネーションが可視性やプライバシーとどのように機能するかによって、ページが空になることもありますが、'next'ページングリンクは含まれています。'next'リンクが表示されない場合は、ページングを停止してください。
  • previous :データの前のページを返すグラフAPIエンドポイントです。含まれていない場合、これはデータの最初のページになります。

ページネーションされるアイテムリストに新しいオブジェクトが追加されると、各オフセットベースページのコンテンツが変わります。

オフセットベースのページネーションは、API呼び出しではサポートされていません。一貫した結果を得るには、応答で返されたpreviousリンクやnextリンクを使ってページネーションすることをおすすめします。

文字数の多いリクエストの送信

一部のグラフAPIのエンドポイントでは、非常に文字数の多いパラメーターが取得されることがあります。 リクエストが2,000文字を超える場合、サーバーで文字数が多すぎるGETリクエストは拒否されるため、サーバーエラーが表示されることがあります。

ベストプラクティスとして、文字数の多いリクエストの場合はPOSTリクエストではなく、GETリクエストを使い、method=GETパラメーターを追加することをおすすめします。 これを行うと、POSTGETと同様に解釈されます。

複数リクエストの実行

標準バージョンのグラフAPIは、各オブジェクトのデータ取得やオブジェクト間のつながりの参照を簡単にする目的で作成されています。少量のオブジェクトのデータを同時に取得できる、限定された機能も含まれています。

アプリに、1回の実行で大量のデータにアクセスする機能が必要な場合や、一度に複数のオブジェクトを編集する必要がある場合は、個別のHTTPリクエストを複数回実行するよりも、クエリを一括で行うほうがより効率的です。

グラフAPIでは、クエリを一括で行えるよう、複数ID検索やバッチ処理などのさまざまな機能がサポートされています。バッチリクエストについては、個別のガイドで説明しますが、複数ID検索については以下で詳しく説明します。

複数IDの読み取りリクエスト

GETエンドポイントと、複数ノードのオブジェクトIDを使って、複数ノードを取得する?idsリクエストを1回実行できます。たとえば、Facebook開発者向けページと現在のセッションユーザーを1回のリクエストで探す場合、以下のグラフAPI呼び出しを利用できます。

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検索で使用することはできますが、オブジェクトにリクエストされたフィールドのいずれかがない場合はエラーが返されます。たとえば、この方法を使ってPageとUserを検索し、fields=id,picture,genderでフィルタする場合、Pageにgenderフィールドがないためにリクエストは失敗します。

イントロスペクション

グラフAPIでは、ノードのインストロペクションがサポートされています。イントロスペクションを使うと、事前にノードのタイプがわからない場合でも、ノードのすべてのエッジを表示できます。この情報を取得するには、グラフAPIリクエストに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のほとんどのノードには、ターゲットを公開できるエッジがあります(/{user-id}/feed/{album-id}/photosなど)。すべてのグラフAPIは、必要なパラメーターを含めて関連エッジにHTTP POSTリクエストを送信するだけで公開されます。たとえば、他の人に代わって投稿を公開するには、以下のようにHTTP POSTリクエストを送信します。

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

すべての公開呼び出しは、アクセストークンを使って署名されている必要があります。このアクセストークンで必要なアクセス許可を決めるには、公開するノードについて「グラフAPIリファレンス」で確認してください。

ターゲットを公開できるエッジは多数あります。詳しくは、各ノードのリファレンスドキュメントをご覧ください。

グラフAPIの一般的なシナリオガイドでは、いくつかの一般的な公開シナリオに関する追加情報を紹介しています。

複数リクエストの実行

バッチリクエストを使って、公開呼び出しと読み取り呼び出しを1つにまとめることもできます。詳しくは、「Making Multiple API Requests (複数のAPIリクエストを行う)」をご覧ください。

リードアフターライト

多くのエッジがリードアフターライトをサポートしています。各エンドポイントのリファレンスドキュメントを参照し、リードアフターライトをサポートしているかどうか、どのフィールドを利用できるかをご確認ください。

更新

すべてのグラフAPIは、すべての更新されたパラメーターを含めて関連ノードにHTTP POSTリクエストを送信することによって更新されます。

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

すべての更新呼び出しは、更新するノードの「グラフAPIリファレンス」に記載されているように、そのエンドポイントへの公開に必要なものと同じアクセス許可を含むアクセストークンで署名されている必要があります。

リードアフターライト

多くのエッジがリードアフターライトをサポートしています。各エンドポイントのリファレンスドキュメントを参照し、リードアフターライトをサポートしているかどうか、どのフィールドを利用できるかをご確認ください。

削除

ノードを削除するには、ノードにHTTP DELETEリクエストを発行します。

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

一般的には、削除できるのはそのアプリで作成したコンテンツのみです。ノードやエッジについて詳しくは、リファレンスドキュメントをご覧ください。

一部のHTTPメソッドをサポートしていないクライアントをサポートするには、追加の引数POSTを使ってエンドポイントにmethod=deleteリクエストを発行し、HTTPメソッドを上書きします。たとえば、以下のリクエストを発行してコメントを削除できます。

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

リードアフターライト

作成とアップデートのエンドポイントでは、グラフAPIが公開またはアップデートに成功したオブジェクトを即座に読み取り、対応する読み取りエンドポイントでサポートしているフィールドを返します。

この機能を使用するには、リクエストに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からは通常のエラー応答が返されます。さらに応答には、成功した場合にエンドポイントから返される値である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検索クエリでは、リクエストにアクセストークンが含まれている必要があります。検索を実行するには、ユーザーアクセストークンが必要です。

利用できる検索タイプ

以下の検索タイプがサポートされています。

タイプ 説明 `q`値

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:内部サポートIDグラフAPI呼び出しに関するバグを報告する際、fbtrace_idを含めて、Facebookがデバッグ用のログデータを見つけやすいようにしてください。

エラーコード

コードまたはタイプ 名称 対処法

OAuthException

サブコードが存在しない場合、ログインステータスかアクセストークンの有効期限が切れている、取り消されている、または無効になっていることを意味します。新しいアクセストークンを取得してください

サブコードが存在する場合は、サブコードを確認します。

102

API Session (APIセッション)

サブコードが存在しない場合、ログインステータスかアクセストークンの有効期限が切れている、取り消されている、または無効になっていることを意味します。新しいアクセストークンを取得してください

サブコードが存在する場合は、サブコードを確認します。

1

API Unknown (API不明)

ダウンタイムによる一時的な問題である可能性があります。しばらく待ってから操作を再試行してください。問題が再発する場合は、既存のAPIをリクエストしていることを確認します。

2

API Service (APIサービス)

ダウンタイムによる一時的な問題です。しばらく待ってから操作を再試行してください。

4

API Too Many Calls (APIの呼び出し回数が上限を超えました)

スロットリングによる一時的な問題です。しばらく待ってから操作を再試行するか、APIリクエストのボリュームを確認してください。

17

API User Too Many Calls (API利用者の呼び出し回数が上限を超えました)

スロットリングによる一時的な問題です。しばらく待ってから操作を再試行するか、APIリクエストのボリュームを確認してください。

10

API Permission Denied (APIのアクセス許可が拒否されました)

アクセス許可が付与されていないか、削除されています。不足しているアクセス許可を処理してください

190

Access token has expired (アクセストークンが有効期限切れになっています)

新しいアクセストークンを取得してください

200-299

API Permission (APIのアクセス許可)(アクセス許可により複数の値)

アクセス許可が付与されていないか、削除されています。不足しているアクセス許可を処理してください

341

Application limit reached (アプリケーションの上限に達しました)

ダウンタイムまたはスロットリングによる一時的な問題です。しばらく待ってから操作を再試行するか、APIリクエストのボリュームを確認してください。

368

Temporarily blocked for policies violations (ポリシーに違反しているため一時的にブロックされています)

しばらく待ってから操作を再試行してください。

506

Duplicate Post (重複する投稿)

重複する投稿を連続して公開することはできません。投稿の内容を変更して、もう一度実行してください。

1609005

Error Posting Link (投稿リンクのエラー)

提供されたリンクからデータを取得中に問題が発生しました。URLを確認して再試行してください。

サブコードの認証エラー

コード 名称 対処法

458

App Not Installed (アプリがインストールされていません)

ユーザーがアプリにログインしていません。ユーザーを再認証します。

459

User Checkpointed (利用者のチェックポイントが設定されています)

問題を修正するには、ユーザーがhttps://www.facebook.comまたはhttps://m.facebook.comにログインする必要があります。

460

Password Changed (パスワードが変更されました)

iOS 6以上で、利用者がOSに統合されたフローでログインしている場合、デバイスのFacebook OS設定が表示され、そこでパスワードを更新する必要があります。更新しない場合は、アプリにもう一度ログインする必要があります。

463

Expired (期限切れ)

ログインステータスかアクセストークンの有効期限が切れている、取り消されている、または無効になっています。期限切れアクセストークンを処理してください

464

Unconfirmed User (未確認の利用者)

問題を修正するには、ユーザーがhttps://www.facebook.comまたはhttps://m.facebook.comにログインする必要があります。

467

Invalid access token (アクセストークンが無効です)

アクセストークンの有効期限が切れている、取り消されている、または無効になっています。期限切れアクセストークンを処理してください

複合パラメーター

ほとんどのパラメータータイプはstringintのようにわかりやすいプリミティブですが、listobjectといった、リクエストで指定できるタイプもあります。

listタイプは、["firstitem", "seconditem", "thirditem"]のようにJSON構文で指定されます。

objectタイプも、{"firstkey": "firstvalue", "secondKey": 123}のようにJSON構文で指定されます。

APIリクエストのデバッグ

グラフAPIのデバッグモード

デバッグモードが有効な場合、グラフAPI応答に追加フィールド(リクエストに関する考えられる問題についての説明)が含まれていることがあります。

デバッグモードを有効にするには、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

タイプがinfowarningのデバッグメッセージ。

warning

タイプがwarningのデバッグメッセージのみ。

デバッグ情報(該当する場合)が__debug__キー(messages配列内)の下に、JSONオブジェクトとして返されます。この配列のすべてのエレメントはJSONオブジェクトで、以下のフィールドが含まれています。

フィールド データタイプ 説明

メッセージ

文字列

メッセージ自体。

タイプ

文字列

メッセージの重要度。

リンク

文字列

[任意]関連情報を示すURL。

グラフAPIエクスプローラで、デバッグモードを使うこともできます。

APIリクエストで使われているバージョンの確認

アプリの構築中にグラフAPIリクエストを実行する場合、状況によっては応答を取得するAPIのバージョンを確認できると便利です。たとえば、バージョンを指定せずに呼び出しを行うと、応答するAPIバージョンがわからないこともあります。

グラフAPIでは、facebook-api-versionを呼び出すあらゆる応答を含むリクエストヘッダーが提供されます。そこでは応答が生成されたAPIの正確なバージョンが示されます。たとえば、v2.0でリクエストを生成するグラフAPI呼び出しの場合、以下のHTTPヘッダーが含まれます。

facebook-api-version:v2.0

このfacebook-api-versionヘッダーから、API呼び出しが予期しているバージョンから返されたものかどうかを判断できます。

バグ報告用のデバッグ情報

グラフAPIでバグを報告する必要がある場合、Facebookでは、バグレポートと一緒に送信が必要な追加リクエストヘッダーをいくつか含めるようにしています。これらはFacebookが問題の発生場所を把握し、問題を再現する際に役立ちます。これらのリクエストヘッダーには、X-FB-Debugx-fb-revX-FB-Trace-IDがあります。