このドキュメントでは、アプリケーションのパフォーマンスを向上させるためのテクニックをいくつか説明します。場合によっては他の API や汎用 API を使用していますが、Google Drive 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 の構文に基づいています。サポートされている構文を以下にまとめます。その後のセクションで追加の例を挙げて説明します。
- 複数のフィールドを選択するには、カンマ区切りのリストを使用します。
- Use フィールド
a
内にネストされているフィールドb
を選択するにはa/b
と指定します。b
内にネストされているフィールドc
を選択するにはa/b/c
と指定します。
例外: データラッパーを使用する 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
を使用した更新では、必須パラメータを省略するとリクエストは失敗し、任意指定のパラメータを省略するとすでに設定済みのデータがクリアされてしまいます。
このため、パッチを使用したほうが安全です。パッチを使用すれば、変更したいフィールドのデータを指定するだけで済みます。省略したフィールドがクリアされることはありません。このルールの唯一の例外は要素または配列の繰り返しです。繰り返される要素または配列をすべて省略すると、何も変更されません。繰り返される要素または配列のいずれかを指定すると、指定した内容で繰り返し全体が置換されます。
バッチ リクエスト
ここでは、複数のバッチ API 呼び出しを行って、クライアント側の HTTP 接続の回数を減らす方法について説明します。
具体的には、1 件の HTTP リクエストを送信してバッチ リクエストを行う方法を取り上げます。Google クライアント ライブラリを使用してバッチ リクエストを行う場合は、クライアント ライブラリのドキュメントをご覧ください。
概要
クライアントで HTTP 接続を行うたびに、ある程度のオーバーヘッドが発生します。Google Drive API ではバッチ処理がサポートされており、クライアントは複数の API 呼び出しを 1 つの HTTP リクエストにまとめることができます。
バッチ処理は次のような状況で使用します。
- 多数のファイルのメタデータを取得する。
- メタデータまたはプロパティの一括更新。
- 新しいユーザーまたはグループを追加するなど、多数のファイルの権限を変更する。
- ローカルのクライアント データを初めて同期する場合、または長時間オフラインになっている場合。
いずれの場合も、各呼び出しを個別に送信するのではなく、1 つの HTTP リクエストにまとめることができます。内部リクエストはすべて同じ Google API に送信する必要があります。
1 つのバッチ リクエストに含めることができる呼び出しは 100 個までです。それ以上の呼び出しを行う必要がある場合は、複数のバッチ リクエストを使用します。
注: Google Drive API のバッチシステムは OData バッチ処理システムと同じ構文を使用しますが、セマンティクスは異なります。
その他の制約には以下が含まれます。
- 100 件を超える呼び出しを含むバッチ リクエストを行うと、エラーが発生する可能性があります。
- 各内部リクエストの URL の長さは 8,000 文字に制限されています。
- Google ドライブでは、メディアのアップロード、ダウンロード、エクスポートの一括操作はサポートされていません。
バッチ リクエストの詳細
バッチ リクエストは、複数の API 呼び出しを 1 つの HTTP リクエストにまとめたもので、API ディスカバリ ドキュメントで指定されている batchPath
に送信できます。デフォルトのパスは /batch/api_name/api_version
です。このセクションでは、バッチ リクエストの構文について詳しく説明し、最後に例を紹介します。
注: n 件のリクエストを 1 つにまとめたバッチ リクエストは、1 件のリクエストではなく n 件のリクエストとして使用量上限に加算されます。バッチ リクエストは、個々のリクエストに分割されてから処理されます。
バッチ リクエストの形式
バッチ リクエストは multipart/mixed
コンテンツ タイプを使用した単一の標準 HTTP リクエストで、複数の Google Drive API 呼び出しから構成されます。そのメインの HTTP リクエスト内の各パーツには、ネストされた HTTP リクエストが含まれます。
各パーツはそれぞれ Content-Type: application/http
という形式の HTTP ヘッダーで始まり、オプションの Content-ID
ヘッダーを指定することもできます。ただし、パーツヘッダーはパーツの開始箇所を示すためだけに存在していて、ネストされたリクエストとは分かれています。サーバーがバッチ リクエストを別々のリクエストにアンラップした後、パーツヘッダーは無視されます。
各パーツのボディは、独自の動詞、URL、ヘッダー、ボディを含む完全な HTTP リクエストです。これらの HTTP リクエストには URL のパス部分のみを含める必要があり、完全な URL は、バッチ リクエストでは許可されていません。
外側のバッチ リクエストの HTTP ヘッダー(Content-Type
などの Content-
ヘッダー以外)はバッチ リクエスト内の各リクエストに適用されます。ある HTTP ヘッダーを外側のリクエストと個々の呼び出しの両方で指定した場合、個々の呼び出しのヘッダー値は外側のバッチ リクエストのヘッダー値を上書きします。個々の呼び出しのヘッダーはその呼び出しにのみ適用されます。
たとえば、ある呼び出しに Authorization ヘッダーを指定した場合、そのヘッダーはその呼び出しにのみ適用されます。Authorization ヘッダーを外側のリクエストに指定した場合、そのヘッダーはすべての呼び出しに適用されます。ただし、各呼び出しに独自の Authorization ヘッダーを指定している場合は各呼び出しの Authorization ヘッダーで上書きされます。
サーバーがバッチ リクエストを受信すると、外側のリクエストのクエリ パラメータとヘッダー(指定した場合)を各パーツに適用し、各パーツを個別の HTTP リクエストとして処理します。
バッチ リクエストへのレスポンス
サーバーのレスポンスは multipart/mixed
コンテンツ タイプを使用した単一の標準 HTTP レスポンスです。各パーツはバッチ リクエスト内の個々のリクエストに対するレスポンスで、リクエストと同じ順序にネストされます。
レスポンスの各パーツは、リクエストのパーツと同様にステータス コード、ヘッダー、ボディを含む完全な HTTP レスポンスになっています。また、リクエストのパーツと同様に、レスポンスの各パーツはパーツの開始箇所を示す Content-Type
ヘッダーから始まります。
リクエストのパーツに Content-ID
ヘッダーがある場合、対応するレスポンスのパーツには、それに一致する Content-ID
ヘッダーが指定されます。レスポンスのパーツのヘッダーは、以下の例に示すように、元の値の先頭に文字列 response-
が付いた値となります。
注: サーバーはバッチ リクエスト内の呼び出しを順番どおりに処理するとは限りません。指定した順序で実行されると想定しないでください。2 つの呼び出しを特定の順序で実行したい場合は、1 つのバッチ リクエストで送信することはできません。代わりに、最初の呼び出しを送信してレスポンスが返ってきてから、2 番目の呼び出しを送信します。
例
次の例は、Google Drive API でのバッチ処理の使用方法を示しています。
バッチ リクエストの例
POST https://www.googleapis.com/batch/drive/v3 Accept-Encoding: gzip User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip) Content-Type: multipart/mixed; boundary=END_OF_PART Content-Length: 963--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8
{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8
{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--
バッチ レスポンスの例
これは、前のセクションのリクエスト例に対するレスポンスです。
HTTP/1.1 200 OK Alt-Svc: quic=":443"; p="1"; ma=604800 Server: GSE Alternate-Protocol: 443:quic,p=1 X-Frame-Options: SAMEORIGIN Content-Encoding: gzip X-XSS-Protection: 1; mode=block Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk Transfer-Encoding: chunked X-Content-Type-Options: nosniff Date: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Vary: X-Origin Vary: Origin Expires: Fri, 13 Nov 2015 19:28:59 GMT--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1
HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35
{ "id": "12218244892818058021i" }
--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2
HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35
{ "id": "04109509152946699072k" }
--batch_6VIxXCQbJoQ_AATxy_GgFUk--
リクエストから特定のフィールドを返す
デフォルトでは、サーバーはインスタンス固有のリソース フィールド セットを
確認します。たとえば、
files.list
メソッドは
id
、name
、mimeType
。これらのフィールドは、先ほど定義したものとは
できます。他のフィールドを返す必要がある場合は、
ファイルの特定のフィールドを返す。