批次處理的一種特定方法，即全球 HTTP 批次端點 (www.googleapis.com/batch)，已於 2020 年 8 月 12 日終止，如 Google Developers 網誌公告所述。如本頁其餘部分所述，其他批次處理方法仍可使用。如果程式碼使用全域 HTTP 批次端點，請參閱網誌文章來瞭解如何改用其他方法，例如 API 專屬 HTTP 批次端點 (www.googleapis.com/batch/API/VERSION)。
本文說明如何批次處理 API 呼叫，以減少用戶端必須發出的 HTTP 連線數量。
本文件說明如何傳送 HTTP 要求以建立批次要求。但如果您改用 Google 用戶端程式庫發出批次要求，請參閱用戶端程式庫說明文件。
總覽
用戶端建立的每個 HTTP 連線都會造成一定程度的負擔。Google Ad Experience Report API 支援批次處理功能，可讓您的用戶端多次呼叫 API 呼叫。
以下是您可能想要使用批次作業的狀況範例：
- 您剛開始使用 API，有許多資料需要上傳。
- 使用者在您的應用程式離線 (中斷與網際網路的連線) 時變更了資料，所以應用程式必須傳送許多更新和刪除資料，讓本機資料能夠與伺服器同步處理。
在每種情況下，您可以分別將要求歸入同一個 HTTP 要求中，而非個別傳送。所有內部要求必須前往同一個 Google API。
在單一批次要求中，您最多可以呼叫 1000 次呼叫。如果需要呼叫更多項目，請使用多個批次要求。
注意：Google Ad Experience Report API 的批次系統使用的語法與 OData 批次處理系統相同，但語意不同。
批次詳細資料
批次要求是由多個 API 呼叫合併，當中包含一個 HTTP 要求，可傳送至 API 探索文件中指定的 batchPath。預設路徑為 /batch/api_name/api_version。本節詳細說明批次語法，稍後會有範例。
注意：系統會將一個 n 要求批次處理，進而計入用量限制，而非 n 要求。批次要求會先分割為一組要求，再進行處理。
批次要求的格式
批次要求是單一標準 HTTP 要求，內含多個使用 multipart/mixed 內容類型的 Google Ad Experience Report API 呼叫。在主要 HTTP 要求中，每個部分都含有一個巢狀的 HTTP 要求。
每個部分都以自己的 Content-Type: application/http HTTP 標頭開頭。此外，您也可以選擇加入 Content-ID 標頭。但是，標頭標頭只是為了標示零件的開頭；它們與巢狀要求不同。伺服器將批次要求解除包裝成不同要求後，系統會忽略零件標頭。
每個分部的主體本身就是一個完整的 HTTP 要求，有自己的動詞、URL、標頭和內文。HTTP 要求只能包含 URL 的路徑部分；批次要求禁止納入完整的 URL。
外部批次要求中的 HTTP 標頭會套用至批次中的所有要求，但 Content-Type 等 Content- 標頭除外。如果您在外部要求和個別呼叫中均指定所提供的 HTTP 標頭，則個別呼叫標頭的值會覆寫外部批次要求標頭的值。個別呼叫的標頭只會套用於該呼叫。
例如，如果您提供 Authorization 標頭用於特定呼叫，則該標頭只會套用於該呼叫。如果您提供 Authorization 標頭用於外部要求，則除非個別呼叫以自己的 Authorization 標頭覆寫所提供的標頭，否則所提供的 Authorization 標頭會套用於所有個別呼叫。
當伺服器收到批次要求時，即會將外部要求的查詢參數和標頭 (在適用情況下) 套用至每一個分部，然後將每個分部視為不同的 HTTP 要求。
回應批次要求
伺服器的回應是具有 multipart/mixed 內容類型的單一標準 HTTP 回應，每個部分都是批次要求中的一個要求回應，順序與要求相同。
就像要求中的分部一樣，每個回應分部都含有完整的 HTTP 回應，包括狀態碼、標頭和內文；而與要求中的部分一樣，每個回應部分前面會有一個 Content-Type 標頭，標記這些部分的開頭。
如果要求中的特定部分含有 Content-ID 標頭，則回應的對應部分會包含相符的 Content-ID 標頭，且原始值前面會加上字串 response-，如以下範例所示。
注意事項：伺服器得按任意順序執行您的呼叫。不要期望呼叫會按您的指定順序執行。如果您想要確保兩個呼叫依指定順序執行，就不能以單一要求傳送它們，而要先傳送第一個呼叫，然後等到第一個呼叫的回應後才能傳送第二個呼叫。
範例
以下範例說明搭配使用 Google Ad Experience Report API 的批次功能。
批次要求範例
POST /batch/v1?key=key HTTP/1.1 Content-Type: multipart/mixed; boundary=batch_aer --batch_aer Content-Type: application/http Content-ID: id1 GET /v1/sites/http%3A%2F%2F/site1%2F HTTP/1.1 --batch_aer Content-Type: application/http Content-ID: id2 GET /v1/sites/http%3A%2F%2F/site2%2F HTTP/1.1 --batch_aer--
批次回應範例
這是前一節中範例要求的回應。
HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=batch_aer
--batch_aer
Content-Type: application/http
Content-ID: response-id1
HTTP/1.1 200 OK
Content-Type: application/json
{
"reviewedSite": "site1",
"mobileSummary": {
"lastChangeTime": "2019-02-05T09:46:26.521747Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site1/",
"filterStatus": "OFF"
},
"desktopSummary": {
"lastChangeTime": "2019-02-07T23:07:29.017206Z",
"betterAdsStatus": "FAILING",
"enforcementTime": "2018-02-15T15:00:00Z",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site1/",
"filterStatus": "ON"
}
}
--batch_aer
Content-Type: application/http
Content-ID: response-id2
HTTP/1.1 200 OK
Content-Type: application/json
{
"reviewedSite": "site2",
"mobileSummary": {
"lastChangeTime": "2018-03-06T16:06:33.375851Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site2/",
"filterStatus": "OFF"
},
"desktopSummary": {
"lastChangeTime": "2018-03-06T16:06:33.375851Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site2/",
"filterStatus": "OFF"
}
}
--batch_aer--