使用 Graph API

Graph API 是在 Facebook 社交圖表存取和輸出資料的主要方法。這是低級別 HTTP 型 API,可用來查詢資料、發佈新動態、上載相片以及執行各種應用程式可能要進行的工作。本指南會說明如何在 Graph API 中完成所有的任務。

基本資訊

在我們的 Graph API 概覽中,說明 Graph API 的專用術語和結構基本入門。下列部分將進一步說明可使用此 API 執行的各種作業。

讀取

在 Graph API 中,所有節點和邊緣都可以只使用對相關端點的 HTTP GET 要求讀取。例如,如果您想要擷取目前用戶的資訊,應該發出如下 HTTP GET 要求:

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

大部分 API 調用都必須以存取憑證簽署。您可以判斷存取憑證中需要哪些權限,方法是查閱您要讀取的節點或邊緣的 Graph API 參考。您也可以使用 Graph API 測試工具,快速產生存取憑證,以配搭 API 使用,並探索運作方式。

/me 節點是一個特殊端點,會轉移至正使用存取憑證發出 API 調用的用戶 user_id(或 Facebook 專頁的 page_id)。如果您曾有用戶存取憑證,您或許可以使用下列方法,擷取所有用戶的相片:

GET graph.facebook.com
  /me/photos

您接收的回應將根據您所讀取的節點或邊緣而不同,但其回應的一般形式如下:

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

選擇欄位

根據預設,並非所有節點或邊緣中的欄位都會在您進行查詢時傳回。您可以選擇要以 fields 查詢參數回傳的欄位或邊緣。若要讓您的 API 調用更加有效率和快速,這確實相當有用。

舉例來說,使用您個人用戶存取憑證的下列 Graph 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

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

發出巢狀化的要求

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

例如,您可以在單次調用中,要求前 K 本相簿的前 N 張相片。因為這個回應保有資料階層,所以開發人員不需在用戶端上將資料整理在一起。

這與批次要求有所不同,可讓您在單一要求中,發出多個可能彼此不相關的 Graph 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:將傳回資料下一頁的 Graph API 端點。如果未包含這個修飾詞,就會傳回資料的最後一頁。基於分頁利用能見度和私隱設定的方式,有可能某頁為空,但包含「下一頁」的分頁連結。當「下一頁」連結不再出現時,您應該要停止分頁。
  • previous:將傳回資料上一頁的 Graph 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:將傳回資料下一頁的 Graph API 端點。
  • previous:將傳回資料上一頁的 Graph API 端點。

為求結果保持一致,請指定 sinceuntil 參數。此外,建議時差的最大值不要超過 6 個月。

位移型分頁

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

位移分頁的邊緣支援以下參數:

  • offset:依指定數目,將每一頁開頭位移。
  • limit:這是可能可以回傳的物件最大數量。因為經過篩選的關係,查詢回傳的數量可能會少於 limit 的數值。請勿以查詢結果數量少於 limit 的數值來判斷查詢已達到資料清單的盡頭,請改用 next 的存在與否進行判斷(描述如下)。舉例來說,如果您將 limit 設定為 10 然後回傳了 9 個查詢結果,其實可能有更多的資料,但是其中一個項目因為私隱篩選條件而被移除了。 基於效能因素,某些邊緣的 limit 數值也具有最大上限。在所有的情況下,API 都會回傳正確的分頁連結。
  • next:將傳回資料下一頁的 Graph API 端點。如果未包含這個修飾詞,就會傳回資料的最後一頁。基於分頁利用能見度和私隱設定的方式,有可能某頁為空,但包含「下一頁」的分頁連結。當「下一頁」連結不再出現時,您應該要停止分頁。
  • previous:將傳回資料上一頁的 Graph API 端點。如果未包含這個修飾詞,就會傳回資料的第一頁。

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

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

發出較長的要求

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

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

發出多個要求

標準版本的 Graph API 設定目的,是要讓取得個別物件資料以及瀏覽物件之間的連結變得更簡單。此外,目前也包括擷取少數物件資料的有限功能。

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

若要啟用這項功能,Graph API 支援一些函數,包括查詢多個編號和批次處理。在另一份指南中會說明批次要求,但您可以參閱以下查詢多個編號的詳細資訊。

多個編號讀取要求

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

自我檢查

Graph API 有支援節點的自我檢查。可以在不必事先知道類型的情況下,讓您查看節點擁有的所有邊緣。若要取得這項資訊,請將 metadata=1 加入 Graph 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"
   }
}

發佈

Graph API 中大多數節點都有邊緣,可用於發佈目標,例如 /{user-id}/feed/{album-id}/photos。所有的 Graph API 發佈都是透過對相關邊緣發出 HTTP POST 要求以執行,其中包含必要的參數。例如,若要代表用戶發佈帖子,您應該發出如下的 HTTP POST 要求:

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

所有發佈調用都必須以存取憑證簽署。您可以判斷存取憑證中需要哪些權限,方法是查閱您要發佈的目標節點的 Graph API 參考

有非常多的邊緣可以用以發佈目標。請參閱每個節點的參考文件以瞭解詳情。

Graph API 常見案例的指南中也可以找到一些常見發佈情境的其他資訊。

發出多個要求

您可以使用批次要求,將發佈調用和讀取調用串在一起。如需更多資訊,請參閱發出多個 API 要求

先寫後讀

許多邊緣都有支援先寫後讀。請參考每個端點的參考資料文件,以便瞭解是否支援先寫後讀以及可用的欄位。

更新

所有的 Graph API 更新都是透過對相關節點發出 HTTP POST 要求執行即可,其中包含更新的參數:

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

所有更新調用都必須以存取憑證簽署,具有與發佈至端點所需相同的權限,依據您所要更新節點的 Graph API 參考而定。

先寫後讀

許多邊緣都有支援先寫後讀。請參考每個端點的參考資料文件,以便瞭解是否支援先寫後讀以及可用的欄位。

刪除

您可以對節點發出 HTTP DELETE 要求,以便從圖表刪除節點:

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

一般而言,應用程式只能刪除自行建立的內容。請參閱相關節點或邊緣的參考指南以瞭解詳情。

如果用戶端不支援任何 HTTP 方法,您可以改為發出 POST 要求到端點,配搭額外的引數 method=delete,以覆寫 HTTP 方法,支援這些用戶端。例如,您可以發出下列要求來刪除回應:

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

先寫後讀

若要建立並更新端點,Graph 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",
}

請參考每個端點的參考資料文件,以便瞭解是否支援先寫後讀以及可用的欄位。

錯誤

若有任何原因無法讀取(例如要求不存在的欄位),Graph 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}

所有 Graph 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:內部支援識別碼。舉報 Graph 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 OS 設定,以更新密碼。否則,他們必須再次登入應用程式。

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 要求

Graph API 除錯模式

除錯模式啟用後,Graph 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 的最低要求重要性等級:

除錯參數值 會回傳的項目

全部

所有可用的除錯訊息。

資訊

擁有 infowarning 類型的除錯訊息。

警告

只有 warning 類型的除錯訊息。

除錯資訊(如果可用)會從 __debug__ 陣列中的 messages 密鑰內,以 JSON 物件的形式回傳。這個陣列的每個元素都是 JSON 物件,包含下列欄位:

欄位 資料類型 描述

訊息

字串

訊息。

類型

字串

訊息重要性。

連結

字串

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

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

判斷 API 要求所使用的版本

當您建立應用程式和發出 Graph API 要求時,會發現能夠判斷取得回應的 API 版本十分實用。例如,如果您未指定版本而發出調用,您可能無法得知回應的 API 版本。

Graph API 提供要求標頭任何稱為 facebook-api-version 的回應,指出產生這則回應的確切 API 版本。例如,以第 2.0 版產生要求的 Graph API 調用,將具有下列 HTTP 標頭:

facebook-api-version:v2.0

facebook-api-version 標題可以讓您判斷 API 調用是否是從您預期的版本所回傳。

回報錯誤的除錯資訊

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