使用圖形 API

圖形 API 是在 Facebook 社交關係圖存取和輸出資料的主要方法。這是低層級 HTTP 型 API,可用來查詢資料、發佈新動態、上傳相片、以及各種應用程式可能要進行的工作。本指南旨在說明如何透過圖形 API 完成上述所有工作。

基本入門

圖形 API 總覽中,我們會大致介紹圖形 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 將只會傳回您個人檔案的編號、名稱和大頭貼照:

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

網址查詢

大多數物件可以透過編號查詢,但有時候沒辦法這樣做,而且您只能透過網址來識別物件。

您可以使用在第 2.1 版推出的網址節點,以傳回開放社交關係圖物件網址的編號,或是找出與應用程式連結網址相關聯的資料。

在我們的應用程式連結文件中,深入瞭解使用索引 API 找出應用程式連結資料的方式。

修改 API 要求

有些 API 端點可以搭配額外參數使用,以修改要求。因為這些「修飾詞」作用的本質各有不同,所以我們在各篇 API 參考文件的適當位置分別講解。下列為可搭配大多數端點使用的常用修飾詞清單。

名稱 說明 型別

return_ssl_resources

當您要求影像必須透過安全連線(HTTPS)傳回時使用,以避免瀏覽器中混合內容的警告。

bool

locale

當應用程式需要能以特定地區設定的語言擷取本地化內容時使用(如果有的話)。

Locale

下面顯示分頁自我檢查的其他修飾詞。

發出巢狀化的要求

圖形 API 欄位擴展功能讓您可以有效地將多個社交關係圖查詢巢狀化至單一呼叫中。包括大多數廣告 API 在內的特定資源,都無法在部分或所有連線中使用欄位擴展。

例如,您可以在單一呼叫中,要求前 K 本相簿的前 N 張相片。因為回應會維持資料階層,所以開發人員無需在用戶端上將資料整理在一起。

批次要求的功能則有所不同,可讓您在單一要求中,發出多個可能不相關的圖形 API 呼叫。

欄位擴展接受的一般格式如下:

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)

現在,我們可以再擴展為擷取每張相片的名稱、相片網址和已標註的用戶:

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 設為 20,將會找到 20 個物件,但由於隱私篩選的緣故,只會顯示 9 個。如果將 limit 重設為 40,將會找到 40 個物件,但再次由於篩選的緣故,只會傳回 12 個。如果搜尋沒有結果,將不會有分頁,也不會指出有更多項目可用,雖然如果提高 limit 就可能會有更多項目。基於效能因素,某些關係連線的 limit 值同樣具有上限。
  • next:將傳回下一頁資料的圖形 API 端點。如果未包含這個修飾詞,代表傳回資料為最後一頁。由於分頁作業配合能見度和隱私設定的方式,有可能某頁為空白,但卻包含「下一頁」的分頁連結。當「下一頁」連結不再出現時,請即停止詢問分頁。
  • 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 個結果,可能仍有更多資料可使用,但因為隱私篩選功能,而有一項結果遭系統移除。 基於效能因素,某些關係連線的 limit 值同樣具有上限。無論什麼情況,API 都會傳回正確的分頁連結。
  • next:將傳回下一頁資料的圖形 API 端點。
  • previous:將傳回上一頁資料的圖形 API 端點。

為了結果的一致性,請同時指定 sinceuntil 參數。此外,建議時間差最多為 6 個月。

位移型分頁

當您不在乎時間順序,而只想要傳回特定數目的物件時,可使用位移分頁。僅當關係連線不支援游標或時間型分頁時,才應該使用位移分頁。

位移型分頁的關係連線支援下列參數:

  • offset:依指定數目,將每一頁開頭位移。
  • limit:這是可能傳回的物件數量上限。由於篩選功能的緣故,查詢時傳回的物件數量可能低於 limit 的值。請不要根據結果數量少於 limit 值的情形,而標示查詢已來到資料清單的結尾處,請改為使用未包含 next 的方式,如下所述。例如,如果您將 limit 的值設為 10,而系統傳回 9 個結果,可能仍有更多資料可使用,但因為隱私篩選功能,而有一項結果遭系統移除。 基於效能因素,某些關係連線的 limit 值同樣具有上限。無論什麼情況,API 都會傳回正確的分頁連結。
  • next:將傳回下一頁資料的圖形 API 端點。如果未包含這個修飾詞,代表傳回資料為最後一頁。由於分頁作業配合能見度和隱私設定的方式,有可能某頁為空白,但卻包含「下一頁」的分頁連結。當「下一頁」連結不再出現時,請即停止詢問分頁。
  • previous:將傳回上一頁資料的圖形 API 端點。如果未包含這個修飾詞,代表傳回資料為第一頁。

請注意,如果將新的物件加入分頁中的項目清單,每個位移型分頁的內容都會變更。

並非所有 API 呼叫都支援位移型分頁。若要取得一致的結果,建議您使用在回應中傳回的上一頁/下一頁連結來進行分頁。

發出較長的要求

某些圖形 API 端點可以接受相當長的參數。 如果您的要求長度最後超過幾千個字元,因為我們的伺服器會拒絕過長的 GET 要求,所以您可能會開始看到伺服器錯誤。

對於較長的要求,最佳作法是使用 POST 要求,而非 GET 要求,並且新增 method=GET 參數。 如果您這樣做,系統就會將 POST 視同 GET 解讀。

發出多個要求

圖形 API 標準版本的目的是要讓您更容易取得個別物件資料及瀏覽物件之間的連結。此外,也有同時擷取少數物件資料的有限功能。

如果您的應用程式需要一次存取大量資料,或者您需要一次變更多個物件,將查詢以批次處理通常會更有效率,而不是發出多個個別 HTTP 要求。

為了提供這項功能,圖形 API 支援一些函數,包括查詢多個編號和批次處理。在另一份指南中會說明批次要求,但您可以參閱下列查詢多個編號的資訊。

多個編號讀取要求

您可以發出擷取多個節點的單一 GET 要求,方法是使用 ?ids 節點搭配這些節點的物件編號。例如,若要在單一要求中查詢 Facebook 開發人員網頁和目前連線階段的用戶,您可以使用下列圖形 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
  }
}

這也可以搭配關係連線使用,只要所有要求的編號都有要求的關係連線即可。例如:

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

請注意,雖然欄位篩選、欄位擴展和限制可搭配多個編號查詢使用,但如果其中一個物件沒有任何所要求的欄位,就會發生錯誤。例如,如果您使用這個方法查詢粉絲專頁和用戶,然後依據 fields=id,picture,gender 進行篩選,但因為粉絲專頁沒有 gender 欄位,這個要求將會失敗。

自我檢查

圖形 API 支援節點自我檢查。這讓您可以查看節點擁有的所有關係連線,而不必事先知道其類型。若要取得這項資訊,請將 metadata=1 加入圖形 API 要求:

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 常見案例指南中涵蓋一些常見發佈案例的額外資訊。

發出多個要求

您可以使用批次要求,將發佈呼叫和讀取呼叫串連在一起。如需更多資訊,請參閱發出多個 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

傳回可能地標的粉絲專頁主題和其編號的清單。使用 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 呼叫相關錯誤時,請加上 fbtrace_id,以協助我們找出偵錯紀錄資料。

錯誤代碼

代碼或類型 名稱 因應方式

OAuthException

如果未出現子代碼,代表登入狀態或存取權杖已過期、已撤銷,或因其他原因無效。取得新的存取權杖

如果出現子代碼,請參閱子代碼。

102

API 連線階段

如果未出現子代碼,代表登入狀態或存取權杖已過期、已撤銷,或因其他原因無效。取得新的存取權杖

如果出現子代碼,請參閱子代碼。

1

API 未知

可能是停機導致的暫時問題。請稍待片刻後重試這項作業。如果再次發生,請檢查您要求的 API 是否存在。

2

API 服務

停機導致的暫時問題。請稍待片刻後重試這項作業。

4

API 太多呼叫

節流導致的暫時問題。請稍待片刻後重試這項作業,或檢查您的 API 要求量。

17

API 用戶太多呼叫

節流導致的暫時問題。請稍待片刻後重試這項作業,或檢查您的 API 要求量。

10

API 權限遭拒絕

權限未授予或已移除。處理缺少的權限

190

存取權杖已過期

取得新的存取權杖

200-299

API 權限(視權限而定,可能有多個值)

權限未授予或已移除。處理缺少的權限

341

已達到應用程式限制

停機或節流導致的暫時問題。請稍待片刻後重試這項作業,或檢查您的 API 要求量。

368

因違反政策暫時遭到封鎖

請稍待片刻後重試這項作業。

506

重複貼文

重複貼文無法連續發佈。請變更貼文內容,然後再試一次。

1609005

貼文連結錯誤

從提供的連結抓取資料時發生問題。請檢查網址,然後再試一次。

驗證錯誤子代碼

編寫程式碼 名稱 因應方式

458

未安裝應用程式

用戶尚未登入您的應用程式。重新驗證用戶。

459

用戶檢查項目

用戶必須在 https://www.facebook.com 或 https://m.facebook.com 登入以修正問題。

460

密碼已變更

在 iOS 6 和更新版本,如果用戶使用作業系統整合流程登入,須將用戶引導至裝置的 Facebook 作業系統設定,以更新密碼。否則用戶必須再次登入應用程式。

463

已到期

登入狀態或存取權杖已到期、已撤銷,或因其他原因無效。處理到期的存取權杖

464

用戶未確認

用戶必須在 https://www.facebook.com 或 https://m.facebook.com 登入以修正問題。

467

無效的存取權杖

存取權杖已到期、已撤銷,或因其他原因無效。處理到期的存取權杖

複雜參數

大部分的參數類型都是明確的基本類型(如 stringint)。但您也可在要求中指定 listobject 類型。

list 類型會以 JSON 語法指定,例如:["firstitem", "seconditem", "thirditem"]

object 類型也會以 JSON 語法指定,例如:{"firstkey": "firstvalue", "secondKey": 123}

偵錯 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 的偵錯訊息。

偵錯資訊(如果有的話)會以 JSON 物件傳回,位於 messages 陣列中的 __debug__ 索引碼下方。這個陣列的每個元素都是 JSON 物件,包含下列欄位:

欄位 資料類型 說明

message

字串

訊息本身。

type

字串

訊息重要性等級。

link

字串

[選用] 指向相關資訊的網址。

您還可透過 圖形 API 測試工具使用偵錯模式。

判斷 API 要求所使用的版本

當您建立應用程式並發出圖形 API 要求時,會發現能夠判斷回應來自哪個 API 版本是很有用的。例如,如果您未指定版本而發出呼叫,您可能無法得知回應的 API 版本。

圖形 API 的任何回應都會提供稱為 facebook-api-version 的要求標頭,指出產生回應的確切 API 版本。例如,以第 2.0 版產生要求的圖形 API 呼叫,將具有下列 HTTP 標頭:

facebook-api-version:v2.0

這個 facebook-api-version 標頭可讓您判斷 API 呼叫是否從您預期的版本傳回。

回報錯誤的偵錯資訊

如果您需要回報圖形 API 中的錯誤,我們會納入一些其他要求標頭;請與錯誤報告一同傳送,以協助我們準確找出並重現您的問題。這些要求標頭為 X-FB-Debugx-fb-revX-FB-Trace-ID