傳送一個包含多個 Facebook Graph API 呼叫的 HTTP 要求。系統會同時處理獨立的作業,並循序處理相依的作業。所有作業完成後,系統便會向您傳回整合好的回應,並會關閉 HTTP 連線。
回應的順序與要求中的作業順序一致。您應據此處理回應,以確定哪些作業為成功,哪些作業應在後續作業中重試。
批次要求會接受由要求陣列組成的 JSON 物件,並傳回採用 JSON 陣列格式的邏輯 HTTP 回應陣列。每個回應均含有狀態代碼、可選標題陣列和一個可選正文(正文為 JSON 編碼字串)。
如要執行批次要求,請將 POST 要求傳送至 batch 參數為您 JSON 物件的端點。
POST /ENDPOINT?batch=[JSON-OBJECT]
批次要求範例
在此範例中,我們會獲取由我們應用程式管理的兩個專頁之相關資訊。
我們已設定特定格式以便閱讀。curl -i -X POST 'https://graph.facebook.com/me?batch=
[
{
"method":"GET",
"relative_url":"PAGE-A-ID"
},
{
"method":"GET",
"relative_url":"PAGE-B-ID"
}
]
&include_headers=false // Included to remove header information
&access_token=ACCESS-TOKEN'所有作業完成後,系統會傳送包含各項作業結果的回應。由於系統傳回的標題有時會比實際 API 回應大很多,因此您可能需要移除這些標題,以提高效率。如要包含標題資訊,請移除 include_headers 參數,或將其設定為 true。
回應範例
正文欄位包含字串編碼 JSON 物件:
[
{
"code": 200,
"body": "{
\"name\": \"Page A Name\",
\"id\": \"PAGE-A-ID\"
}"
},
{
"code": 200,
"body": "{
\"name\": \"Page B Name\",
\"id\": \"PAGE-B-ID\"
}"
}
]您可將一般會使用不同 HTTP 方法的作業合併至單一批次要求中。GET 和 DELETE 作業只能含有 relative_url 和 method 欄位,而 POST 和 PUT 作業可以包含可選的 body 欄位。與網址查詢字串相同,正文的格式應為原始 HTTP POST 字串。
要求範例
在以下範例中,我們將在同一個作業中,向由我們管理且我們擁有其發佈權限的專頁發佈帖子,然後向專頁的動態消息發佈帖子:
curl "https://graph.facebook.com/PAGE-ID?batch=
[
{
"method":"POST",
"relative_url":"PAGE-ID/feed",
"body":"message=Test status update"
},
{
"method":"GET",
"relative_url":"PAGE-ID/feed"
}
]
&access_token=ACCESS-TOKEN"這個呼叫的輸出如下所示:
[
{ "code": 200,
"headers": [
{ "name":"Content-Type",
"value":"text/javascript; charset=UTF-8"}
],
"body":"{\"id\":\"…\"}"
},
{ "code": 200,
"headers": [
{ "name":"Content-Type",
"value":"text/javascript; charset=UTF-8"
},
{ "name":"ETag",
"value": "…"
}
],
"body": "{\"data\": [{…}]}
}
]下列範例會建立新的宣傳活動廣告,然後取得剛建立的物件之詳細資料。請注意正文參數的 URLEncoding:
curl \
-F 'access_token=...' \
-F 'batch=[
{
"method":"POST",
"name":"create-ad",
"relative_url":"11077200629332/ads",
"body":"ads=%5B%7B%22name%22%3A%22test_ad%22%2C%22billing_entity_id%22%3A111200774273%7D%5D"
},
{
"method":"GET",
"relative_url":"?ids={result=create-ad:$.data.*.id}"
}
]' \
https://graph.facebook.com下列範例會將多個專頁加到企業管理平台:
curl \
-F 'access_token=<ACCESS_TOKEN>' \
-F 'batch=[
{
"method":"POST",
"name":"test1",
"relative_url":"<BUSINESS_ID>/owned_pages",
"body":"page_id=<PAGE_ID_1>"
},
{
"method":"POST",
"name":"test2",
"relative_url":"<BUSINESS_ID>/owned_pages",
"body":"page_id=<PAGE_ID_2>"
},
{
"method":"POST",
"name":"test3",
"relative_url":"<BUSINESS_ID>/owned_pages",
"body":"page_id=<PAGE_ID_3>"
},
]' \
"https://graph.facebook.com/v12.0"其中:
<ACCESS_TOKEN> 是擁有 business_management 權限的存取憑證。<BUSINESS_ID> 是應向其認領專頁的企業管理平台的編號。<PAGE_ID_n> 是要認領的專頁編號。您要求的作業有可能會擲回錯誤。發生這種情況的其中一個原因,是因為您沒有執行所要求作業的權限。這個回應與標準 Graph API 相似,但以批次回應語法封裝:
[
{ "code": 403,
"headers": [
{"name":"WWW-Authenticate", "value":"OAuth…"},
{"name":"Content-Type", "value":"text/javascript; charset=UTF-8"} ],
"body": "{\"error\":{\"type\":\"OAuthException\", … }}"
}
]批次內的其他要求仍會順利完成,然後照常傳回,且狀態代碼為 200。
如果較大或較複雜的批次耗費太多時間,仍無法完成批次內所有要求,就有可能會逾時。在這種情況下,結果將會是部分完成的批次。在部分完成的批次中,順利完成的要求將傳回狀態代碼為 200 的標準輸出。至於未順利完成的要求,回應將為 null。如有任何未成功的要求,您都可以重試。
與其他 Graph API 一樣,批次 API 支援 JSONP。您可以使用 callback 查詢字串或表格發佈參數指定 JSONP 回呼函數。
單一批次要求中的個別要求可以將自己的存取憑證指定為查詢字串或表格發佈參數。在這種情況下,系統會將最上層存取憑證視為遞補憑證,且在個別要求沒有明確指定存取憑證時使用這個憑證。
當您想使用多個不同用戶或專頁存取憑證查詢 API 時,或者當您的某些呼叫必須使用應用程式存取憑證發出,這個功能便可派上用場。
您必須將存取憑證加入為最上層參數,即使所有個別要求都已包含自己的憑證也是如此。
您可以在批次呼叫時上載多個二進制項目。如要做到這一點,您必須將所有二進制項目當成 multipart/mime 附件加入您的要求,而且各項作業也必須使用作業中的 attached_files 屬性來參照其二進制項目。attached_files 屬性的值中可以加入逗號分隔的附件名稱清單。
下列範例示範如何在單一批次呼叫中上載 2 張相片:
curl
-F 'access_token=…' \
-F 'batch=[{"method":"POST","relative_url":"me/photos","body":"message=My cat photo","attached_files":"file1"},{"method":"POST","relative_url":"me/photos","body":"message=My dog photo","attached_files":"file2"},]' \
-F 'file1=@cat.gif' \
-F 'file2=@dog.jpg' \
https://graph.facebook.com