Melhorar o desempenho

Este documento aborda algumas técnicas que você pode usar para melhorar o desempenho do aplicativo. Em alguns casos, exemplos de outras APIs ou de APIs genéricas são usados para ilustrar as ideias apresentadas. No entanto, os mesmos conceitos são aplicáveis à API Google Drive.

Compactação com o gzip

Uma maneira fácil e conveniente de reduzir a largura de banda necessária a cada solicitação é ativar a compactação gzip. Embora isso exija mais tempo de CPU para descompactar os resultados, a redução dos custos de rede normalmente faz com que esse método valha muito a pena.

Para receber uma resposta codificada em gzip, você precisa definir um cabeçalho Accept-Encoding e modificar seu user agent para conter a string gzip. Veja um exemplo de cabeçalhos HTTP formados devidamente para permitir a compactação gzip:

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

Como trabalhar com recursos parciais

Outra maneira de melhorar o desempenho das chamadas da API é enviar e receber somente a parte dos dados que você quer. Assim, evita-se a transferência, a análise e o armazenamento de campos desnecessários no aplicativo para que recursos como rede, CPU e memória sejam usados de maneira mais eficiente.

Há dois tipos de solicitações parciais:

  • Resposta parcial: uma solicitação em que você especifica quais campos serão incluídos na resposta. Use o parâmetro de solicitação fields.
  • Patch: uma solicitação de atualização em que você envia somente os campos que serão alterados. Use o verbo HTTP PATCH.

Nas seções a seguir são fornecidos mais detalhes sobre como fazer solicitações parciais.

Resposta parcial

Por padrão, depois de processar as solicitações, o servidor envia de volta a representação completa de um recurso. Para melhorar o desempenho, solicite ao servidor o envio apenas dos campos realmente necessários para receber uma resposta parcial.

Para solicitar uma resposta parcial, use o parâmetro de solicitação fields para especificar os campos a serem retornados. Use esse parâmetro com qualquer solicitação que retorne dados de resposta.

Observe que o parâmetro fields afeta apenas os dados de resposta. Ele não afeta os dados que você precisa enviar, se houver. Para reduzir a quantidade de dados enviados durante a modificação de recursos, use uma solicitação de patch.

Exemplo

O exemplo a seguir mostra o uso do parâmetro fields com uma API "Demo" genérica (fictícia).

Solicitação simples: essa solicitação HTTP GET omite o parâmetro fields e retorna o recurso completo.

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

Resposta de recursos completos: os dados de recursos completos incluem os campos a seguir, além de muitos outros omitidos para agilizar o processo.

{
  "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",
    ...
  },
  ...
  ]
}

Solicitação de uma resposta parcial: na solicitação a seguir, para esse mesmo recurso, o parâmetro fields é usado para reduzir de modo significativo a quantidade de dados retornados.

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

Resposta parcial: em reação à solicitação acima, o servidor envia de volta uma resposta que contém somente as informações de tipo, além de uma matriz de itens pareados com características de tamanho e título HTML em cada item.

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

Observe que a resposta é um objeto JSON que contém apenas os campos selecionados e os respectivos objetos pais.

Veja detalhes sobre como formatar o parâmetro fields a seguir, seguidos por mais detalhes sobre o que exatamente é retornado na resposta.

Resumo da sintaxe do parâmetro "Campos"

O formato do valor do parâmetro da solicitação fields baseia-se vagamente na sintaxe XPath. Veja abaixo um resumo da sintaxe compatível e outros exemplos.

  • Use uma lista separada por vírgulas para selecionar diversos campos.
  • Use a/b para selecionar um campo b aninhado no campo a. Use a/b/c para selecionar um campo c aninhado em b.

    Exceção: Para respostas da API que usam wrappers "data", em que a resposta é aninhada em um objeto data semelhante a data: { ... }, não inclua "data" na especificação fields. A inclusão do objeto de dados com uma especificação de campos como data/a/b causa um erro. Em vez disso, basta usar uma especificação fields como a/b.

  • Use um sub-seletor para solicitar um conjunto de subcampos específicos de matrizes ou objetos. Basta colocar expressões entre parênteses "( )".

    Por exemplo: fields=items(id,author/email) retorna apenas o ID do item e o e-mail do autor para cada elemento na matriz de itens. Também é possível especificar um único subcampo, em que fields=items(id) é equivalente a fields=items/id.

  • Se necessário, use caracteres curinga em seleções de campo.

    Por exemplo: fields=items/pagemap/* seleciona todos os objetos em um pagemap.

Mais exemplos do uso do parâmetro fields

Os exemplos abaixo incluem descrições de como o valor do parâmetro fields afeta a resposta.

Observação: assim como com todos os valores de parâmetro de consulta, fields também precisa ter codificação de URL. Para facilitar a leitura, os exemplos neste documento estão sem a codificação.

Identifique os campos a serem retornados ou faça seleções de campos.
O valor de parâmetro da solicitação fields é uma lista de campos separados por vírgulas e cada campo é especificado em relação à raiz da resposta. Portanto, se você estiver executando uma operação de lista, a resposta será uma coleção que, geralmente, inclui uma matriz de recursos. Se você estiver executando uma operação que retorne um único recurso, os campos serão especificados em relação a esse recurso. Se o campo selecionado for uma matriz, ou parte dela, o servidor retornará a parte selecionada de todos os elementos na matriz.

Veja alguns exemplos do nível de coleção:
Exemplos Efeito
items Retorna todos os elementos da matriz de itens, incluindo todos os campos em cada elemento, mas nenhum outro campo.
etag,items Retorna o campo etag e todos os elementos na estrutura de itens.
items/title Retorna apenas o campo de title para todos os elementos da matriz de itens.

Sempre que um campo aninhado for retornado, a resposta incluirá os respectivos objetos pais. Os campos pai não incluem outro campo filho, a menos que eles também sejam selecionados explicitamente.
context/facets/label Retorna apenas o campo label para todos os membros da matriz facets, que é aninhada sob o objeto context.
items/pagemap/*/title Para cada elemento na matriz de itens, retorna apenas o campo title, se presente, de todos os objetos filhos de pagemap.

Veja alguns exemplos no nível do recurso:
Exemplos Efeito
title Retorna o campo title do recurso solicitado.
author/uri Retorna o subcampo uri do objeto author no recurso solicitado.
links/*/href
 Retorna o campo href de todos os objetos filhos de links.
Solicite apenas partes de campos específicos usando subseleções.
Por padrão, se houver campos particulares especificados na solicitação, todos os objetos ou elementos da matriz serão retornados pelo servidor. É possível especificar uma resposta que inclua apenas determinados subcampos. Para isso, use a sintaxe de subseleção "( )", como no exemplo abaixo.
Exemplo Efeito
items(title,author/uri) Retorna apenas os valores de title e uri do autor para cada elemento na matriz de itens.

Como processar respostas parciais

Depois que o servidor processar uma solicitação válida que inclua o parâmetro de consulta fields, ele retorna um código de status 200 OK HTTP, junto com os dados solicitados. Se o parâmetro de consulta fields tiver um erro ou for inválido, o servidor retornará um código de status HTTP 400 Bad Request com uma mensagem informando ao usuário o que havia de errado com a seleção de campos. Por exemplo, "Invalid field selection a/b".

Veja o exemplo de resposta parcial mostrado na seção introdutória acima. A solicitação usa o parâmetro fields para especificar os campos que precisam ser retornados.

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

A resposta parcial é semelhante a esta:

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

Observação: em APIs compatíveis com parâmetros de consulta para paginação de dados (por exemplo, maxResults e nextPageToken), use esses parâmetros para reduzir os resultados de cada consulta a um tamanho administrável. Caso contrário, os possíveis ganhos de desempenho talvez não se concretizem.

Patch (atualização parcial)

É possível também evitar o envio de dados desnecessários ao modificar recursos. Para enviar dados atualizados apenas nos campos que estiverem sendo alterados, use o verbo HTTP PATCH. A semântica do patch descrita neste documento é diferente e mais simples do que aquela da implementação de atualização parcial do GData, que é mais antiga.

Veja no pequeno exemplo abaixo como o uso do patch minimiza os dados necessários para fazer uma pequena atualização.

Exemplo

Neste exemplo, há uma solicitação simples de patch para atualizar apenas o título do recurso de uma "Demo" API genérica (fictícia). O recurso também tem um comentário, um conjunto de características, status e muitos outros campos, mas essa solicitação envia apenas o campo title, porque esse é o único campo que está sendo modificado:

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

{
  "title": "New title"
}

Resposta:

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

O servidor retorna um código de status 200 OK e a representação completa do recurso atualizado. Como apenas o campo title foi incluído na solicitação de patch, esse é o único valor diferente de antes.

Observação: se você usar o parâmetro fields da resposta parcial em combinação com um patch, será possível aumentar ainda mais a eficiência de suas solicitações de atualização. Uma solicitação de correção só reduz o tamanho da solicitação. Uma resposta parcial reduz o tamanho da resposta. Portanto, para reduzir a quantidade de dados enviados nas duas direções, use uma solicitação de patch com o parâmetro fields.

Semântica de uma solicitação de patch

O corpo da solicitação de patch inclui somente os campos do recurso que você quer modificar. Ao especificar um campo, é necessário incluir qualquer objeto pai que tiver sido inserido, assim como os pais inseridos são retornados com uma resposta parcial. Os dados modificados que você envia são mesclados com os dados do objeto pai, se houver um.

  • Adicionar: para adicionar um campo que ainda não existe, especifique o novo campo e o valor correspondente.
  • Modificar: para alterar o valor de um campo existente, especifique o campo e configure-o como o novo valor.
  • Excluir: para excluir um campo, especifique-o e configure-o como null. Por exemplo, "comment": null. Você também pode excluir um objeto inteiro (se for mutável) configurando-o como null. Se você estiver usando a biblioteca de cliente da API Java, use Data.NULL_STRING. Para mais detalhes, consulte JSON null.

Observação sobre matrizes: solicitações de patch que contenham matrizes substituem a matriz existente pela fornecida por você. Não é possível modificar, adicionar ou excluir itens em uma matriz facilmente.

Como usar patch em um ciclo de leitura-modificação-gravação

Pode ser útil começar com a recuperação de uma resposta parcial com os dados que quer modificar. Isso é especialmente importante para recursos que usam ETags, porque é preciso fornecer o valor de ETag atual no cabeçalho HTTP If-Match para atualizar o recurso com êxito. Depois de receber os dados, você poderá modificar os valores que quer alterar e reenviar a representação parcial modificada com uma solicitação de correção. Veja um exemplo que pressupõe que o recurso de demonstração usa ETags:

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

Esta é a resposta parcial:

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

A solicitação de patch a seguir é baseada nessa resposta. Como mostrado abaixo, ela também usa o parâmetro fields para limitar os dados retornados na resposta do patch:

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. */
  },
}

O servidor responde com um código de status HTTP "200 OK" e a representação parcial do recurso atualizado:

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. */
  }
}

Como criar uma solicitação de patch diretamente

Algumas solicitações de patch precisam ser baseadas nos dados recuperados anteriormente. Por exemplo, para adicionar um item a uma matriz sem perder elementos dela, primeiro extraia os dados atuais. Da mesma maneira, se uma API usa ETags, é necessário enviar o valor anterior da ETag com sua solicitação para atualizar o recurso corretamente.

Observação: use um cabeçalho HTTP "If-Match: *" para forçar a passagem de um patch quando as ETags forem usadas. Se fizer isso, não será preciso fazer a leitura antes da gravação.

Porém, em outras situações, é possível construir a solicitação de patch diretamente, sem recuperar os dados atuais antes. Por exemplo, é fácil configurar uma solicitação de patch que atualiza um campo com um novo valor ou adiciona um novo campo. Veja um exemplo:

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
  }
}

Se o campo estiver vazio, essa solicitação definirá um valor, caso contrário, ela substituirá o valor atual. Da mesma maneira, se houvesse uma característica de volume, o valor seria substituído. Caso contrário, um novo seria criado. O campo "accuracy", se definido, seria removido.

Processar resposta para um patch

Após processar uma solicitação de patch válida, a API retorna um código de resposta HTTP 200 OK com a representação completa do recurso modificado. Caso a API use ETags, o servidor atualizará os valores delas durante o processamento de uma solicitação de patch, como acontece com PUT.

A solicitação de correção retorna toda a representação do recurso, a menos que você use o parâmetro fields para reduzir a quantidade de dados retornados.

Se uma solicitação de correção resultar em um novo estado de recurso sintático ou semanticamente inválido, o servidor retornará um código de status HTTP 400 Bad Request ou 422 Unprocessable Entity e o estado do recurso permanecerá inalterado. Por exemplo, ao tentar excluir o valor de um campo obrigatório, o servidor retorna um erro.

Notação alternativa quando não houver suporte para o verbo HTTP PATCH

Caso o firewall não permita solicitações de HTTP PATCH, faça uma solicitação HTTP POST e configure o cabeçalho de substituição como PATCH. Veja o exemplo abaixo:

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

Diferença entre patch e atualização

Na prática, ao enviar dados para uma solicitação de atualização que usa o verbo HTTP PUT, basta enviar os campos obrigatórios ou opcionais. Os valores enviados para campos definidos pelo servidor serão ignorados. Embora possa parecer outro método de se fazer uma atualização parcial, esta abordagem tem algumas limitações. Com atualizações que usam o verbo HTTP PUT, a solicitação falha quando não são fornecidos parâmetros obrigatórios, e remove dados já definidos quando parâmetros opcionais não são informados.

É muito mais seguro usar o patch por esse motivo. Você fornece somente os dados dos campos que quer alterar. Os campos omitidos não são apagados. A única exceção a essa regra ocorre com matrizes ou elementos repetidos. Se você os omite, eles ficam como estão. Se fornece parte deles, o conjunto inteiro é substituído pelo conjunto fornecido.

Solicitações em lote

Este documento mostra como reunir chamadas à API em lote para reduzir o número de conexões HTTP que seu cliente tem que fazer.

Neste documento, falamos especificamente sobre como fazer uma solicitação em lote enviando uma solicitação HTTP. Se, em vez disso, você estiver usando uma biblioteca de cliente do Google para fazer uma solicitação em lote, consulte a documentação da biblioteca de cliente (em inglês).

Visão geral

Cada conexão HTTP feita pelo cliente resulta em certa quantidade de overhead. A API Google Drive é compatível com lotes para permitir que seu cliente coloque várias chamadas de API em uma única solicitação HTTP.

Exemplos de situações em que convém usar operações em lote:

  • Recuperar metadados de um grande número de arquivos.
  • Atualizar metadados ou propriedades em massa.
  • Alterar permissões para um grande número de arquivos, como adicionar um novo usuário ou grupo.
  • Sincronizar dados de clientes locais pela primeira vez ou depois de ficar off-line por um longo período.

Em cada caso, em vez de enviar cada chamada separadamente, você pode agrupá-las em uma única solicitação HTTP. Todas as solicitações internas precisam ser encaminhadas para a mesma API do Google.

O limite é de 100 chamadas em uma única solicitação em lote. Se você precisar fazer mais chamadas do que isso, use várias solicitações em lote.

Observação: o sistema de lote da API Google Drive usa a mesma sintaxe do sistema de processamento em lote OData (em inglês), mas a semântica é diferente.

Outras restrições incluem:

  • As solicitações em lote com mais de 100 chamadas podem causar um erro.
  • Há um limite de 8.000 caracteres no comprimento do URL para cada solicitação interna.
  • O Google Drive não é compatível com operações em lote de mídia, tanto para upload, download quanto para exportação de arquivos.

Detalhes do lote

Uma solicitação em lote consiste em várias chamadas de API combinadas em uma solicitação HTTP, que pode ser enviada ao batchPath especificado no documento de descoberta de API (em inglês). O caminho padrão é /batch/api_name/api_version. Nesta seção, você verá a descrição em detalhes da sintaxe do lote e, em seguida, um exemplo.

Observação: um conjunto de n solicitações em lote é contabilizado no seu limite de uso, como n solicitações, e não como uma única solicitação. A solicitação em lote é separada em um conjunto de solicitações antes do processamento.

Formato de uma solicitação em lote

Uma solicitação em lote é uma única solicitação HTTP padrão contendo várias chamadas à API Google Drive usando o tipo de conteúdo multipart/mixed. Dentro dessa solicitação HTTP principal, cada parte contém uma solicitação HTTP aninhada.

Cada parte começa com seu próprio cabeçalho HTTP Content-Type: application/http. Também é possível ter um cabeçalho Content-ID opcional. No entanto, os cabeçalhos das partes estão lá apenas para marcar o início da parte. Eles são separados da solicitação aninhada. Depois que o servidor desencapsular a solicitação em solicitações separadas, os cabeçalhos das partes serão ignorados.

O corpo de cada parte é uma solicitação HTTP completa, com o próprio verbo, URL, cabeçalhos e corpo. A solicitação HTTP precisa conter apenas a parte do caminho do URL. URLs completos não são permitidos em solicitações em lote.

Os cabeçalhos HTTP da solicitação em lote externa, exceto os cabeçalhos Content-, como Content-Type, aplicam-se a todas as solicitações no lote. Se você especificar um determinado cabeçalho HTTP na solicitação externa e em uma chamada individual, o valor do cabeçalho da chamada individual substituirá o valor do cabeçalho da solicitação em lote externa. Os cabeçalhos de uma chamada individual aplicam-se somente a ela.

Por exemplo, se você fornecer um cabeçalho de autorização para uma chamada específica, esse cabeçalho só se aplicará a essa chamada. Se você fornecer um cabeçalho de autorização para a solicitação externa, esse cabeçalho se aplicará a todas as chamadas individuais, a menos que ele seja substituído por cabeçalhos de autorização próprios.

Ao receber a solicitação em lote, o servidor aplica os parâmetros e os cabeçalhos de consulta da solicitação externa (conforme apropriado) a cada parte e trata cada parte como se fosse uma solicitação HTTP separada.

Resposta a uma solicitação em lote

A resposta do servidor é uma única resposta HTTP padrão com um tipo de conteúdo multipart/mixed. Cada parte refere-se à resposta a uma das solicitações na solicitação em lote, na mesma ordem das solicitações.

Assim como as partes na solicitação, cada parte da resposta contém uma resposta HTTP completa, inclusive código de status, cabeçalhos e corpo. E da mesma forma que as partes na solicitação, cada parte da resposta é precedida por um cabeçalho Content-Type que marca o início da parte.

Se uma determinada parte da solicitação tiver um cabeçalho Content-ID, a parte correspondente da resposta terá um cabeçalho Content-ID correspondente, com o valor original precedido pela string response-, conforme mostrado no exemplo a seguir.

Observação: o servidor pode realizar as chamadas em qualquer ordem. Não conte com a execução delas na ordem especificada. Se quiser garantir que duas chamadas ocorram em uma determinada ordem, não as envie em uma única solicitação. Em vez disso, envie a primeira e aguarde a resposta antes de enviar a segunda.

Exemplo

O exemplo a seguir mostra o uso de lotes com a API Google Drive.

Exemplo de solicitação em lote

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--

Exemplo de resposta em lote

Esta é a resposta à solicitação de exemplo da seção anterior:

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--

Retornar campos específicos da solicitação

Por padrão, o servidor retorna um conjunto padrão de campos de recurso específicos para o método usado. Por exemplo, o files.list pode retornar apenas o id, name e mimeType. Talvez esses campos não sejam exatamente os que você precisam. Se você precisar retornar outros campos, consulte Retornar campos específicos para um arquivo.