Compression using gzip

An easy and convenient way to reduce the bandwidth needed for each request is to enable gzip compression. Although this requires additional CPU time to uncompress the results, the trade-off with network costs usually makes it very worthwhile.

In order to receive a gzip-encoded response you must do two things: Set anAccept-Encoding header, and modify your user agent to contain the stringgzip. Here is an example of properly formed HTTP headers for enabling gzip compression:

Accept-Encoding:gzipUser-Agent:myprogram (gzip)

Working with partial resources

Another way to improve the performance of your API calls is by sending and receiving only the portion of the data that you're interested in. This lets your application avoid transferring, parsing, and storing unneeded fields, so it can use resources including network, CPU, and memory more efficiently.

There are two types of partial requests:

• Partial response: A request where you specify which fields to include in the response (use thefields request parameter).
• Patch: An update request where you send only the fields you want to change (use thePATCH HTTP verb).

More details on making partial requests are provided in the following sections.

Partial response

By default, the server sends back the full representation of a resource after processing requests. For better performance, you can ask the server to send only the fields you really need and get apartial response instead.

To request a partial response, use thefields request parameter to specify the fields you want returned. You can use this parameter with any request that returns response data.

Note that thefields parameter only affects the response data; it does not affect the data that you need to send, if any. To reduce the amount of data you send when modifying resources, use apatch request.

Patch (partial update)

You can also avoid sending unnecessary data when modifying resources. To send updated data only for the specific fields that you’re changing, use the HTTPPATCH verb. The patch semantics described in this document are different (and simpler) than they were for the older, GData implementation of partial update.

The short example below shows how using patch minimizes the data you need to send to make a small update.

Example

Handling the response to a patch

After processing a valid patch request, the API returns a 200 OK HTTP response code along with the complete representation of the modified resource. If ETags are used by the API, the server updates ETag values when it successfully processes a patch request, just as it does with PUT.

The patch request returns the entire resource representation unless you use thefields parameter to reduce the amount of data it returns.

If a patch request results in a new resource state that is syntactically or semantically invalid, the server returns a400 Bad Request or 422 Unprocessable Entity HTTP status code, and the resource state remains unchanged. For example, if you attempt to delete the value for a required field, the server returns an error.

Alternate notation when PATCH HTTP verb is not supported

If your firewall does not allow HTTP PATCH requests, then do an HTTP POST request and set the override header to PATCH, as shown below:

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

Difference between patch and update

In practice, when you send data for an update request that uses the HTTPPUT verb, you only need to send those fields which are either required or optional; if you send values for fields that are set by the server, they are ignored. Although this might seem like another way to do a partial update, this approach has some limitations. With updates that use the HTTPPUT verb, the request fails if you don't supply required parameters, and it clears previously set data if you don't supply optional parameters.

It's much safer to use patch for this reason. You only supply data for the fields you want to change; fields that you omit are not cleared. The only exception to this rule occurs with repeating elements or arrays: If you omit all of them, they stay just as they are; if you provide any of them, the whole set is replaced with the set that you provide.

Overview

Each HTTP connection your client makes results in a certain amount of overhead. The Google Drive API supports batching, to allow your client to put several API calls into a single HTTP request.

Examples of situations when you might want to use batching:

• Retrieving metadata for a large number of files.
• Updating metadata or properties in bulk.
• Changing permissions for a large number of files, such as adding a new user or group.
• Synchronizing local client data for the first time or after being offline for an extended time.

In each case, instead of sending each call separately, you can group them together into a single HTTP request. All the inner requests must go to the same Google API.

You're limited to 100 calls in a single batch request. If you must make more calls than that, use multiple batch requests.

Note: The batch system for the Google Drive API uses the same syntax as theOData batch processing system, but the semantics differ.

Additional constraints include:

• Batch requests with more than 100 calls might cause an error.
• There's an 8,000 character limit on the length of the URL for each inner request.
• Google Drive doesn't support batch operations for media, either for upload or download, or for exporting files.

Batch details

A batch request consists of multiple API calls combined into one HTTP request, which can be sent to thebatchPath specified in theAPI discovery document. The default path is/batch/api_name/api_version. This section describes the batch syntax in detail; later, there's anexample.

Note: A set ofn requests batched together counts toward your usage limit asn requests, not as one request. The batch request is separated into a set of requests before processing.

Format of a batch request

A batch request is a single standard HTTP request containing multiple Google Drive API calls, using themultipart/mixed content type. Within that main HTTP request, each of the parts contains a nested HTTP request.

Each part begins with its ownContent-Type: application/http HTTP header. It can also have an optionalContent-ID header. However, the part headers are just there to mark the beginning of the part; they're separate from the nested request. After the server unwraps the batch request into separate requests, the part headers are ignored.

The body of each part is a complete HTTP request, with its own verb, URL, headers, and body. The HTTP request must only contain the path portion of the URL; full URLs are not allowed in batch requests.

The HTTP headers for the outer batch request, except for theContent- headers such asContent-Type, apply to every request in the batch. If you specify a given HTTP header in both the outer request and an individual call, then the individual call header's value overrides the outer batch request header's value. The headers for an individual call apply only to that call.

For example, if you provide an Authorization header for a specific call, then that header applies only to that call. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls unless they override it with Authorization headers of their own.

When the server receives the batched request, it applies the outer request's query parameters and headers (as appropriate) to each part, and then treats each part as if it were a separate HTTP request.

Response to a batch request

The server's response is a single standard HTTP response with amultipart/mixed content type; each part is the response to one of the requests in the batched request, in the same order as the requests.

Like the parts in the request, each response part contains a complete HTTP response, including a status code, headers, and body. And like the parts in the request, each response part is preceded by aContent-Type header that marks the beginning of the part.

If a given part of the request had aContent-ID header, then the corresponding part of the response has a matchingContent-ID header, with the original value preceded by the stringresponse-, as shown in the following example.

Note: The server might perform your calls in any order. Don't count on their being executed in the order in which you specified them. If you want to ensure that two calls occur in a given order, you can't send them in a single request; instead, send the first one by itself, then wait for the response to the first one before sending the second one.

Example

The following example shows the use of batching with the Google Drive API.

Example batch request

POST https://www.googleapis.com/batch/drive/v3Accept-Encoding: gzipUser-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)Content-Type: multipart/mixed; boundary=END_OF_PARTContent-Length: 963
--END_OF_PARTContent-Length: 337Content-Type: application/httpcontent-id: 1content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=idAuthorization: Bearerauthorization_tokenContent-Length: 70Content-Type: application/json; charset=UTF-8
{  "emailAddress":"example@appsrocks.com",  "role":"writer",  "type":"user"}--END_OF_PARTContent-Length: 353Content-Type: application/httpcontent-id: 2content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=falseAuthorization: Bearerauthorization_tokenContent-Length: 58Content-Type: application/json; charset=UTF-8
{   "domain":"appsrocks.com",   "role":"reader",   "type":"domain"}--END_OF_PART--

Example batch response

This is the response to the example request in the previous section.

HTTP/1.1 200 OKAlt-Svc: quic=":443"; p="1"; ma=604800Server: GSEAlternate-Protocol: 443:quic,p=1X-Frame-Options: SAMEORIGINContent-Encoding: gzipX-XSS-Protection: 1; mode=blockContent-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUkTransfer-Encoding: chunkedX-Content-Type-Options: nosniffDate: Fri, 13 Nov 2015 19:28:59 GMTCache-Control: private, max-age=0Vary: X-OriginVary: OriginExpires: Fri, 13 Nov 2015 19:28:59 GMT
--batch_6VIxXCQbJoQ_AATxy_GgFUkContent-Type: application/httpContent-ID: response-1
HTTP/1.1 200 OKContent-Type: application/json; charset=UTF-8Date: Fri, 13 Nov 2015 19:28:59 GMTExpires: Fri, 13 Nov 2015 19:28:59 GMTCache-Control: private, max-age=0Content-Length: 35
{ "id": "12218244892818058021i"}
--batch_6VIxXCQbJoQ_AATxy_GgFUkContent-Type: application/httpContent-ID: response-2
HTTP/1.1 200 OKContent-Type: application/json; charset=UTF-8Date: Fri, 13 Nov 2015 19:28:59 GMTExpires: Fri, 13 Nov 2015 19:28:59 GMTCache-Control: private, max-age=0Content-Length: 35
{ "id": "04109509152946699072k"}
--batch_6VIxXCQbJoQ_AATxy_GgFUk--