このページは Cloud Translation API によって翻訳されました。

パフォーマンス向上のヒント

このドキュメントでは、アプリケーションのパフォーマンスを向上させるためのテクニックをいくつか説明します。場合によっては他の API や汎用 API を使用していますが、Directory API にも同じ概念を適用できます。

gzip を使用した圧縮

各リクエストに必要な帯域幅を削減するための簡単で便利な方法として、gzip 圧縮を有効にする方法があります。この方法では、結果を解凍するために CPU 時間が余分に必要になりますが、ネットワーク費用とのバランスを考えると、時間をかける価値は十分にあります。

gzip でエンコードされたレスポンスを受け取るには、2 つの準備作業が必要です。1 つは、Accept-Encoding ヘッダーを設定すること、もう 1 つは、ユーザーエージェントに gzip という文字列を追加することです。以下に、gzip 圧縮を有効にするための正しい形式の HTTP ヘッダーの例を示します。

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

リソースの部分的な使用

API 呼び出しのパフォーマンスを向上させるためのもう 1 つの方法は、データの必要な部分のみを送受信することです。これにより、アプリケーションが不要なフィールドを転送、解析、格納することがなくなるため、ネットワーク、CPU、メモリなどのリソースをより効率的に使用できます。

部分リクエストには次の 2 種類があります。

部分レスポンス: どのフィールドをレスポンスに含めるかを指定するリクエスト（fields リクエストパラメータを使用）。
パッチ: 変更するフィールドのみを送信する更新リクエスト（PATCH HTTP 動詞を使用）。

以下の各セクションで、部分リクエストの作成方法の詳細について説明します。

部分レスポンス

デフォルトでは、サーバーはリクエストを処理した後、リソースを完全な形で返します。パフォーマンスを向上させるには、サーバーが必要なフィールドのみを送信し、それによって部分レスポンスを取得するように指定します。

部分レスポンスをリクエストするには、fields リクエストパラメータを使用して取得するフィールドを指定します。このパラメータは、レスポンスデータを返す任意のリクエストに指定できます。

fields パラメータはレスポンスデータにのみ影響を与えます。送信する必要があるデータには影響を与えません。リソースを変更するときに送信するデータ量を削減するには、patch リクエストを使用します。

例

以下の例では、fields パラメータの使い方を汎用的な（架空の）Demo API を用いて示します。

シンプルなリクエスト: 次の HTTP GET リクエストでは fields パラメータを省略し、リソース全体を取得します。

https://www.googleapis.com/demo/v1

全リソースレスポンス: 全リソースデータには以下のフィールドが含まれます（他にも多くのフィールドがありますが簡略化するため一部のみ表示しています）。

{
  "kind": "demo",
  ...
  "items": [
  {
    "title": "First title",
    "comment": "First comment.",
    "characteristics": {
      "length": "short",
      "accuracy": "high",
      "followers": ["Jo", "Will"],
    },
    "status": "active",
    ...
  },
  {
    "title": "Second title",
    "comment": "Second comment.",
    "characteristics": {
      "length": "long",
      "accuracy": "medium"
      "followers": [ ],
    },
    "status": "pending",
    ...
  },
  ...
  ]
}

部分的レスポンスのリクエスト: 同じリソースに対する次のリクエストでは、fields パラメータを使用しているため、返されるデータが大幅に少なくなります。

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

部分レスポンス: サーバーは上記のリクエストに対し、種類情報と情報が削減されたアイテム配列のみからなるレスポンスを返します。アイテム配列の各アイテムには HTML タイトルと長さ特性情報のみが含まれます。

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

レスポンスとして返されるのは、選択したフィールドとそのフィールドが属する親オブジェクトのみを含む JSON オブジェクトです。

次のセクションで、fields パラメータの形式の指定方法について説明し、さらにその後に、レスポンスとして返される具体的な内容について詳細に説明します。

fields パラメータの構文のまとめ

fields リクエストパラメータの形式は、XPath の構文に基づいています。サポートされている構文を以下にまとめます。その後のセクションで追加の例を挙げて説明します。

複数のフィールドを選択するには、カンマ区切りのリストを使用します。
フィールド a 内にネストされているフィールド b を選択するには a/b を使用し、フィールド a 内にネストされているフィールド c を選択するには a/b/c を使用します。b

例外: データラッパーを使用する API レスポンスは、data: { ... } のように data オブジェクト内にネストされているので、fields の指定に data を含めません。data/a/b のように、fields の指定に data オブジェクトを含めるとエラーになります。この場合は、fields を a/b のように指定してください。
サブセレクタを使用して特定の配列またはオブジェクトのサブフィールドのセットをリクエストするには、式をかっこ「( )」で囲みます。
たとえば、fields=items(id,author/email) と指定すると、items 配列内の各要素について、アイテム ID と作者のメールアドレスのみが返されます。サブフィールドは 1 つだけでもかまいません。たとえば、fields=items(id) と指定するのと fields=items/id と指定するのは同じことです。
必要に応じて、フィールドの選択にワイルドカードを使用します。
たとえば fields=items/pagemap/* とすると、pagemap のすべてのオブジェクトが選択されます。

fields パラメータのその他の使用例

以下にいくつか例を挙げて、fields パラメータ値がレスポンスに与える影響を説明します。

注: 他のすべてのクエリパラメータの値と同じように、fields パラメータ値には URL エンコードを使用する必要があります。このドキュメントの例では、読みやすさを優先してエンコードを省略しています。

返して欲しいフィールドを特定する（フィールド選択を行う）

fields リクエストパラメータ値はフィールドのカンマ区切りのリストであり、各フィールドは、レスポンスのルートからの相対位置で指定します。したがって、リストオペレーションを実行する場合、レスポンスは通常、リソースの配列が格納されたコレクションです。単一のリソースを返すオペレーションを実行する場合、各フィールドは当該リソースからの相対位置で指定します。選択したフィールドが配列（または配列の一部）である場合、サーバーは、配列内のすべての要素について、選択された部分を返します。

以下に、コレクションレベルの例を挙げます。

例	効果
`items`	items 配列内のすべての要素を返します。各要素内のすべてのフィールドが含まれますが、その他のフィールドは含まれません。
`etag,items`	`etag` フィールドと items 配列内のすべての要素を返します。
`items/title`	items 配列内のすべての要素の `title` フィールドのみを返します。ネストされたフィールドが返される場合、レスポンスにはそのフィールドを含む親オブジェクトも必ず含まれます。親フィールド内のその他の子フィールドは、明示的に選択されていない限り含まれません。
`context/facets/label`	`context` オブジェクトにネストされている `facets` 配列内のすべてのメンバーの `label` フィールドのみを返します。
`items/pagemap/*/title`	items 配列内の各要素について、`pagemap` のすべての子オブジェクトの `title` フィールド（存在する場合）のみを返します。

リソースレベルの例を以下に示します。

例	効果
`title`	リクエストされたリソースの `title` フィールドを返します。
`author/uri`	リクエストされたリソースの `author` オブジェクトの `uri` サブフィールドを返します。
`links/*/href`	`links` のすべての子オブジェクトの `href` フィールドを返します。

部分選択を使用して個々のフィールドの一部のみをリクエストする

デフォルトでは、リクエストに特定のフィールドを指定すると、サーバーは、オブジェクト全体または配列要素全体を返します。こうした場合に、レスポンスが特定のサブフィールドのみを含むよう指定するには、下の例のような「( )」部分選択構文を使用します。

例	効果
`items(title,author/uri)`	items 配列内の各要素について、`title` と作者の `uri` の値のみを返します。

部分レスポンスの処理

fields クエリパラメータを含む有効なリクエストを処理した後、サーバーは HTTP 200 OK ステータスコードとともにリクエストされたデータを返します。fields クエリパラメータにエラーがある場合、またはパラメータが無効な場合、サーバーは、HTTP 400 Bad Request ステータスコードとフィールド選択の問題箇所を示すメッセージ（例: "Invalid field selection a/b"）を返します。

以下は、前出の導入セクションで挙げた部分レスポンスの例です。このリクエストでは、どのフィールドを返すかを fields パラメータで指定しています。

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

部分レスポンスは、たとえば次のようになります。

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

注: maxResults や nextPageToken など、データのページ設定のためのクエリパラメータをサポートする API では、こうしたパラメータを使用して各クエリの結果を適切なサイズに制限してください。そうしないと、部分レスポンスによるパフォーマンスの向上が得られないことがあります。

パッチ（部分更新）

リソースを変更する際に不要なデータの送信を回避する方法もあります。変更する個々のフィールドについてのみ更新したデータを送信するには、HTTP 動詞 PATCH を使用します。このドキュメントで説明する PATCH 構文は、部分更新の古い実装 GData の PATCH 構文に比べて簡素化されています。

以下に示す簡単な例は、パッチを使用して、小さな更新を行うために送信する必要があるデータを最小化する方法を示しています。

例

以下の例では、簡単なパッチリクエストを使用して、汎用的な（架空の）Demo API リソースのタイトルのみを更新する方法を示します。リソースには、コメント、特徴のセット、ステータスなど、多数のフィールドがありますが、このリクエストで変更するのは title フィールドのみですので、このフィールドだけを送信します。

PATCH https://www.googleapis.com/demo/v1/324
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "title": "New title"
}

対応:

200 OK

{
  "title": "New title",
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "accuracy": "high",
    "followers": ["Jo", "Will"],
  },
  "status": "active",
  ...
}

サーバーからは、200 OK のステータスコードと更新されたリソースが完全な表現で返されます。パッチリクエストに含まれていたのは title フィールドだけなので、更新前と異なるのはこのフィールドだけです。

注: 部分レスポンスの fields パラメータをパッチと組み合わせて使用すれば、更新リクエストの効率をさらに高めることができます。パッチリクエストはリクエストのサイズのみを小さくし、部分的レスポンスはレスポンスのサイズのみを小さくします。このことから、双方向のデータ送信量を削減するには、パッチリクエストに fields パラメータを指定します。

パッチリクエストの構文

パッチリクエストの本文には、変更するリソースフィールドのみを含めます。フィールドを指定する際には、そのフィールドが存在する親オブジェクトも含める必要があります。これは、部分レスポンスで親オブジェクトが返されるのと同じです。親オブジェクトが存在する場合、送信した変更対象データは親オブジェクトのデータとマージされます。

追加: フィールドを新しく追加するには、新規のフィールドとその値を指定します。
変更: 既存のフィールドの値を変更するには、そのフィールドを指定して、新しい値を設定します。
削除: フィールドを削除するには、そのフィールドを指定し null に設定します。例: "comment": null。オブジェクト全体を削除するには（オブジェクトが変更可能な場合）、オブジェクトに null を設定します。Java API クライアントライブラリを使用する場合は、代わりに Data.NULL_STRING を使用します。詳細については、JSON null をご覧ください。

配列に関する注意: 配列を含むパッチリクエストを実行すると、既存の配列が指定した配列で置換されます。配列内の要素を部分的に変更、追加、削除することはできません。

パッチを読み取り-変更-書き込みサイクルで使用する

変更する必要のあるデータの部分レスポンスを取得することから始めてみると良い練習になります。これは、ETag を使用するリソースでは特に重要になります。このようなリソースは、If-Match HTTP ヘッダーに最新の ETag 値を指定しないと、正常に更新できないからです。データを取得したら、値の変更を設定し、変更部分のみを記述した部分的な表現をパッチリクエストで送り返します。次の例は、demo リソースで ETag が使用されていることを前提としています。

GET https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token

部分レスポンスは次のようになります。

200 OK

{
  "etag": "ETagString"
  "title": "New title"
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "level": "5",
    "followers": ["Jo", "Will"],
  }
}

以下のパッチリクエストは、上記のレスポンスを使用しています。以下に示すとおり、このリクエストでは fields パラメータを使用して、パッチレスポンスで返されるデータを制限しています。

PATCH https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json
If-Match: "ETagString"

{
  "etag": "ETagString"
  "title": "",                  /* Clear the value of the title by setting it to the empty string. */
  "comment": null,              /* Delete the comment by replacing its value with null. */
  "characteristics": {
    "length": "short",
    "level": "10",              /* Modify the level value. */
    "followers": ["Jo", "Liz"], /* Replace the followers array to delete Will and add Liz. */
    "accuracy": "high"          /* Add a new characteristic. */
  },
}

サーバーからは、200 OK HTTP ステータスコードと、リソースの更新された部分が返されます。

200 OK

{
  "etag": "newETagString"
  "title": "",                 /* Title is cleared; deleted comment field is missing. */
  "characteristics": {
    "length": "short",
    "level": "10",             /* Value is updated.*/
    "followers": ["Jo" "Liz"], /* New follower Liz is present; deleted Will is missing. */
    "accuracy": "high"         /* New characteristic is present. */
  }
}

パッチリクエストを直接作成する

一部のパッチリクエストは、あらかじめ取得しておいたデータに基づいて作成する必要があります。たとえば、配列にアイテムを追加したいが、既存の配列要素はそのまま維持したい場合は、最初に既存のデータを取得する必要があります。同様に、API で ETag が使用されている場合は、変更前の ETag 値をリクエストとともに送信しないと、リソースを正常に更新できません。

注: HTTP の "If-Match: *" ヘッダーを使用して、ETag の使用中にパッチの実行を強制できます。その場合は、書き込む前に読み取る必要はありません。

上記のようなケースを除けば、事前に既存のデータを取得することなく、パッチリクエストを直接作成できます。たとえば、フィールドを新しい値に更新するパッチリクエストや新しいフィールドを追加するパッチリクエストを簡単にセットアップできます。以下に例を示します。

PATCH https://www.googleapis.com/demo/v1/324?fields=comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "comment": "A new comment",
  "characteristics": {
    "volume": "loud",
    "accuracy": null
  }
}

このリクエストでは、comment フィールドに既存の値が存在する場合は、新しい値で既存の値が上書きされ、そうでない場合は、新しい値が設定されます。同様に、volume 特性が存在する場合は、その値が上書きされ、存在しない場合は作成されます。accuracy フィールドが設定されている場合は、削除されます。

パッチに対するレスポンスを処理する

有効なパッチリクエストを処理すると、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 を使用した更新では、必須パラメータを省略するとリクエストは失敗し、任意指定のパラメータを省略するとすでに設定済みのデータがクリアされてしまいます。

このため、パッチを使用したほうが安全です。パッチを使用すれば、変更したいフィールドのデータを指定するだけで済みます。省略したフィールドがクリアされることはありません。このルールの唯一の例外は要素または配列の繰り返しです。繰り返される要素または配列をすべて省略すると、何も変更されません。繰り返される要素または配列のいずれかを指定すると、指定した内容で繰り返し全体が置換されます。