Ce guide explique les différences entre les versions 1 et 2 de l'API Google Drive Activity, et comment modifier votre application v1 pour qu'elle prenne en charge l'API v2.
Autorisation
L'API v1 utilisait cette portée:
https://www.googleapis.com/auth/activity
L'API v2 nécessite l'un des champs d'application suivants:
https://www.googleapis.com/auth/drive.activityhttps://www.googleapis.com/auth/drive.activity.readonly
Noms de ressources
Dans l'API v1, les identifiants d'objets tels que les éléments et les utilisateurs Google Drive étaient des chaînes opaques. Dans l'API v2, ces objets sont généralement référencés à l'aide de noms de ressources. Pour en savoir plus, consultez le guide de conception d'API Cloud.
Ces identifiants peuvent généralement être convertis. Par exemple, les éléments Drive de l'API v2 sont référencés à l'aide du nom de ressource items/ITEM_ID_V1.
Demandes
Le format de requête de la version 2 est semblable à celui de la version 1. Plus précisément, vous pouvez toujours demander une activité pour un fichier Drive ou un ancêtre Drive. Notez toutefois que vous devez mettre en forme ces paramètres de requête en tant que noms de ressources en leur ajoutant le préfixe items/.
"Groupement" est désormais appelé Consolidation, et les paramètres de requête source et userId ont été supprimés.
De nouvelles options de filtrage vous permettent également de limiter les types de données d'activité renvoyés dans la réponse.
Actions
Dans l'API v1, le type d'activité et les données associées à cette activité se trouvaient dans des champs distincts. Par exemple, si le champ primaryEventType contient la valeur move, les applications supposent qu'un champ move de niveau supérieur est renseigné avec les parents ajoutés et supprimés.
Dans l'API v2, ces champs ne sont plus distincts. Le message ActionDetail comporte exactement un seul champ défini. Il indique le type d'action et contient les détails associés à cette action. Par exemple, un ActionDetail représentant un déplacement ne définit que le champ move, et ce champ liste les parents ajoutés et supprimés.
Le champ primaryEventType de l'API v1 correspond à peu près au primaryActionDetail de la version v2.
Actors
Dans l'API v1, l'activité renvoyée contenait un User si l'acteur était un utilisateur connu et, éventuellement, un champ de niveau supérieur tel que fromUserDeletion pour les cas particuliers.
Dans l'API v2, un ensemble plus riche de types Actor est disponible, et user.knownUser est renseigné lorsque l'acteur est un utilisateur connu. Si votre application a besoin d'informations détaillées sur les utilisateurs, elle peut les interroger à partir de l'API People en transmettant le champ KnownUser personName à la méthode people.get.
Cibles
Dans l'API v1, les cibles étaient toujours des éléments Drive. Dans l'API v2, les cibles peuvent être d'autres types d'objets dans Drive. Par exemple, les modifications apportées à un disque ont un type de cible Drive. Le dossier racine d'un Drive partagé est toujours renvoyé (en tant que DriveItem dans le champ root), mais il ne s'agit pas de la cible immédiate de l'activité. Un concept similaire s'applique à une ressource FileComment, dont le champ parent fait référence à l'élément Drive contenant le fil de discussion de commentaires cible.
Activité consolidée
Dans l'API v1, le style de réponse changeait lorsqu'une stratégie de consolidation ("grouping") était définie. Plus précisément, lorsque la consolidation était activée, chaque activité contenait le singleEvents constituant et un combinedEvent qui résumait l'activité commune entre ces événements constituants. Lorsque la consolidation était désactivée, le champ combinedEvent contenait l'événement d'origine non consolidé pour chaque activité. Chacun de ces événements peut représenter plusieurs actions, comme une création et un partage.
Dans l'API v2, le style de réponse ne change pas en fonction de la stratégie de consolidation, car l'DriveActivity renvoyé contient toujours l'ensemble complet des acteurs, des cibles et des actions.