Guia de comparação da API Drive v2 e v3

A versão mais recente da API Google Drive é a v3. O desempenho na v3 é melhor porque as pesquisas retornam apenas um subconjunto de campos. Use a versão atual, a menos que você precise a coleção v2. Se você estiver usando a v2, considere migração para a v3. Para migrar, consulte Migrar para a API Drive v3. Para uma lista completa das diferenças de versão, consulte a comparação da API Drive v2 e v3 como referência.

Caso queira continuar usando a v2, consulte o Guia da API Drive v2 para saber como algumas instruções na v3 precisam ser alterados para desenvolvedores da v2.

Para saber mais sobre as melhorias da API Drive v3, assista ao vídeo vídeo a seguir de engenheiros do Google discutindo o novo design da API.

Melhorias na V3

Para otimizar o desempenho e reduzir a complexidade do comportamento da API, a v3 oferece essas melhorias em relação à versão anterior da API:

  • Por padrão, as pesquisas por arquivos e drives compartilhados não retornam recursos completos. apenas um subconjunto dos campos usados com frequência é retornado. Para mais detalhes sobre fields, consulte o método files.list. e o método drives.list.
  • Quase todos os métodos que retornam uma resposta agora exigem o fields. . Para uma lista de todos os métodos que exigem fields, consulte a Referência da API Drive.
  • Os recursos com funcionalidades duplicadas foram removidos. Alguns exemplos:
    • O método files.list tem a mesma funcionalidade que o Children e Parents, por isso são removidas da v3.
    • Os métodos Realtime.* foram removidos.
  • Os dados do app não são retornados por padrão nas pesquisas. Na v2, é possível definir escopo drive.appdata e retorna dados do aplicativo do files.list e o método changes.list mas isso prejudica o desempenho. Na v3, você define o escopo drive.appdata, e também definir o parâmetro de consulta spaces=appDataFolder para solicitar dados de aplicativos.
  • Todas as operações de atualização usam PATCH em vez de PUT.
  • Para exportar documentos do Google, use o método files.export.
  • O comportamento do método changes.list é diferente. Em vez de IDs de mudança, use tokens de página opacos. Para pesquisar a coleção de alterações, primeiro chame o método changes.getStartPageToken para o valor inicial. Para consultas subsequentes, o changes.list retorna o valor newStartPageToken.
  • Os métodos de atualização agora rejeitam solicitações que especificam campos não graváveis.
  • Os campos exportFormats e importFormats da v2 no about são listas de formatos de importação ou exportação permitidos. Na v3, eles são mapas do tipo MIME de possíveis destinos a todas as importações ou exportações compatíveis.
  • Os aliases appdata e appfolder da v2 agora são appDataFolder na v3.
  • O recurso properties foi removido da v3. O O recurso files tem o campo properties. que contém pares de chave-valor verdadeiros. O campo properties contém dados públicos e o campo appProperties contém propriedades particulares. Portanto, o campo de visibilidade não é necessário.
  • O campo modifiedTime no recurso files foi atualizado pela última vez e qualquer pessoa modificou o arquivo. Na v2, o campo modifiedDate só era mutável na atualização se você definir o campo setModifiedDate.
  • O campo viewedByMeTime no recurso files não define automaticamente atualizar.
  • Para importar formatos do Documentos Google, você define o mimeType de destino apropriado. no corpo do recurso. Na v2, você define ?convert=true.
  • As operações de importação retornam um erro 400 quando não há suporte para o formato.
  • Os leitores e comentadores não podem ver as permissões.
  • O alias me das permissões foi removido.
  • Algumas funcionalidades estavam disponíveis como parte do recurso da solicitação, mas ainda disponível como um parâmetro de solicitação. Exemplo:
    • Na v2, é possível usar children.delete para remover um arquivo secundário de um na pasta principal.
    • Na v3, você usa files.update no filho com ?removeParents=parent_id no URL.

Outras diferenças

Campos e nomes de parâmetros são diferentes na v3. Veja alguns exemplos:

  • A propriedade name substitui title no recurso files.
  • Time é o sufixo de todos os campos de data e hora em vez de Date.
  • As operações de lista não usam o campo items para conter o conjunto de resultados. O tipo de recurso fornece um campo para os resultados (como files ou changes).