提升效能

本文說明提升應用程式成效的幾個技巧。在某些情況下，我們會使用其他 API 或通用 API 的範例來說明這些技巧背後的概念。不過，同樣的概念也適用於 Android Over The Air API。

使用 gzip 壓縮

要減少每個要求占用的頻寬，最簡單的方法就是使用 gzip 壓縮檔。雖然此方法需要額外的 CPU 作業時間解壓縮，但相對可省下可觀的網路成本。

如果要接收以 gzip 編碼的回應，您必須執行下列兩項操作：設定 Accept-Encoding 標頭，並修改您的使用者代理程式來加入字串 gzip。以下是一個啟用 gzip 壓縮的正確 HTTP 標頭格式範例：

Accept-Encoding: gzip
User-Agent: my program (gzip)

使用部分資源

另一種提高 API 呼叫成效的方式，就是只收發您有興趣的資料。這麼做可避免讓您的應用程式傳輸、剖析及儲存不需要的欄位，進而更有效地使用網路、CPU 以及記憶體等資源。

部分要求分為兩類：

• 部分回應：您可以在這類要求中，指定要在回應中加入哪些欄位 (使用 fields 要求參數)。
• 修補：透過這類更新要求，您可以只傳送想要變更的欄位 (使用 PATCH HTTP 動詞)。

接下來的章節將會詳細說明如何提交部分要求。

部分回應

根據預設，伺服器會在處理要求後傳回完整的資源表示法。為改善成效，您可以要求伺服器只傳送您真正需要的欄位，並改為取得「部分回應」。

如果要請求部分回應，請使用 fields 要求參數來指定您想要傳回的欄位。您可以將此參數搭配任何會傳回回應資料的要求使用。

請注意，fields 參數只會影響回應資料；不會影響您需要傳送的資料 (如果有的話)。如果要減少您在修改資源時傳送的資料量，請使用修補要求。

範例

修補 (部分更新)

修改資源時，您也可以避免傳送不必要的資料。如果是僅為要變更的特定欄位傳送更新資料，請使用 HTTP PATCH 動詞。相較於舊版的 GData 部分更新執行方式，在本文中，「修補」一詞的語意變得更加簡單。

下面的簡短範例將會示範如何使用修補功能，在進行小規模更新時將您需要傳送的資料量減到最小。

範例

處理修補回應

API 會在處理完有效的修補要求之後，傳回 200 OK HTTP 回應代碼以及修改後資源的完整表示法。如果 API 有使用 ETag 的話，伺服器會在成功處理完修補要求時更新 ETag 的值，就像 PUT 一樣。

修補要求會傳回整個資源表示法，除非您使用 fields 參數來減少傳回的資料量。

如果 修補 要求產生的新資源狀態具有無效的語法或語意，則伺服器會傳回 400 Bad Request 或 422 Unprocessable Entity HTTP 狀態碼，且資源狀態維持不變。舉例來說，如果您嘗試刪除必填欄位的值，則伺服器會傳回錯誤。

當 PATCH HTTP 動詞未受支援時可使用的替代標示方法

如果您的防火牆禁止使用 HTTP PATCH 要求，請執行 HTTP POST 要求，並將替換標頭設定為 PATCH，如下所示：

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

修補和更新之間的差異

就實務層面而言，為使用了 HTTP PUT 動詞的更新要求傳送資料時，您只需要傳送必填或選填欄位；如果您傳送了由伺服器設定的欄位值，這些值將會遭到忽略。雖然這看起來像是執行部分更新的另一種方法，但此方法有一些限制存在。使用 HTTP PUT 動詞進行更新時，如果您沒有提供必要參數，則要求將會失敗；此外，如果您沒有提供選用參數，則要求將會清除先前設定的資料。

這也是在此情況下使用修補更加安全的原因。您只需要為您想要變更的欄位提供資料，而您省略的欄位將不會被清除。此規則唯一的例外便是重複元素或陣列：如果您全數省略，它們將會保持原狀；如果您提供了任何重複元素或陣列，則整組元素或陣列都會替換成您提供的組合。