This is documentation which I'm using - https://developers.google.com/drive/api/v3/search-parameters
Does anyone know the way of getting through Google Drive API, the number of times the file was downloaded, views(ideal views by whom)...
I could not find any way of doing this.
Google drive files are denoted by a file resource this contains all the information that you have access to about the file. Only some of the information you are after is available
createdTime datetime The time at which the file was created (RFC 3339 date-time). writable
modifiedTime datetime The last time the file was modified by anyone (RFC 3339 date-time).
Note that setting modifiedTime will also update modifiedByMeTime for the user.
lastModifyingUser nested object The last user to modify the file.
You can see who last changed the file but you cant see who has seen the file or any information about how many times it was downloaded.
Related
I have an application where I need to keep local copies of some of my user's Google Spreadsheets, and this copy should be in sync with the Google Drive version. I've been testing two methods of tracking changes to a Google Spreadsheet: (1) the file version polling method and (2) the files.watch method.
1) The file version polling method
In this method, whenever I need the most recent version of a Spreadsheet (for instance, when the user wants to download the file from my application), I retrieve the file version from Google using:
POST https://www.googleapis.com/drive/v3/files/FILE_ID?fields=version
If the version is greater than the version I have stored on my end, I know that changes have been made and the file on my end is outdated. So I download the file and update my copy.
The problem is that it takes a while for the file version number to be updated on Google's end. Ideally, after editing a Google Spreadsheet cell, my application should be able to detect this change within less than 10 seconds. However, after editing a cell and seeing the Saved to Drive confirmation at the top, sometimes it takes seconds, other times it takes minutes before the version number gets updated, so it is very inconsistent.
Aside from the version number, I've also tried polling the modifiedTime value to see if it changed sooner, but it didn't. So I tried another method.
2) The files.watch method
In this method, I keep track of the file changes by registering a webhook to receive change notifications from Google:
POST https://www.googleapis.com/drive/v3/files/FILE_ID/watch
Whenever I receive a change notification, I know that I need to update my local copy.
Unfortunately, the change notifications also don't happen as quick as I would like. It also has very inconsistent delays: sometimes taking a few seconds, sometimes taking more than a minute.
UPDATE (3) The 'always export' method? Never cache method?
To complicate matters, it seems that even if I ignore my local copy and always try to download the latest version of the file directly from Google, the downloaded file will not necessarily be the absolute latest version that the user sees on the Spreadsheets editor. I tried that using
GET https://www.googleapis.com/drive/v3/files/FILE_ID/export?mimeType=application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
but it would often return the outdated version, and sometimes would only return the latest version after a few minutes.
Is there something else that I can try? The above methods use the Google Drive Files API, but if there is a way to detect changes sooner using the Google Spreadsheets API, I would like to know.
1. How to detect file changes as soon as possible?
After a file change (in my case, a change in a Google Spreadsheet), the version does not get updated immediately, and when you watch for file changes with the files.watch API you will also not get a notification immediately.
What does get updated immediately is the list of revisions of the file, which can be retrieved with the revisions.list API:
GET https://www.googleapis.com/drive/v3/files/FILE_ID/revisions
This returns a list of all revisions of the file FILE_ID. The last item in the list is the most recent revision (the "head" revision). In order to know if a file has changed, I retrieve this list. If the id of head revision is different from the id stored in my end, it means that my local copy is outdated, so I have to update the file and its revision id.
However, if you call files.export, the file version returned will not necessarily be the absolute most recent version (e.g., the Google Sheet you are seeing in your browser). And in the case of Google editor documents, it is not possible to retrieve the most recent revision using the revisions.get API. What can you do then?
2. How to retrieve the most recent revision of a Google Sheet?
(I bet it works for other Google editor documents as well).
Before calling files.export, you have to "touch" the file using the files.update API, updating its modifiedTime:
PATCH https://www.googleapis.com/drive/v3/files/fileId
{
"modifiedTime": "TIMESTAMP"
}
Where TIMESTAMP is a date with the format 2022-04-16T22:00:00Z.
For some reason, touching the file like this "forces" Google to return the head revision of the file the next time you call files.export:
GET https://www.googleapis.com/drive/v3/files/FILE_ID/export?mimeType=MIMETYPE
In my case, MIMETYPE is application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.
That's it. So far, this has been working for me.
My question is similar to What is format of Google Drive's FileID ? I need to find out whether new File has been uploaded to my drive or not using API's but I want to know the format of a folder ID in Google Drive, the one that appears in the URL bar when you open a folder in your Google drive, the thing after https://drive.google.com/drive/u/0/folders/<this part>.
Google Drive folder id doesn't have a specific guaranteed format. This (apparent format which really isn't a format) has changed in the past and may change again.
Trying to create any kind of local verification of this will be futile.
The best option would be to do a Files: get and test if you get a response. This will work better as it will also verify that the user has access to the file as well as testing that its a valid file id format.
Any (regex) attempt to verify the file id wouldn't really verify it as its not going to test if the user has access.
A folder ID starts with a 1 followed by 32 base-64 encoded digits, except unlike base64 the + is replaced by - and / is replaced by _. You can use the following regex:
/^1[A-Za-z0-9-_]{32}$/
The Google Drive API v2 to v3 migration guide says:
The exportLinks field has been removed from files. To export Google Documents, use the files.export method instead.
I don't want to export (download) the file right away. "files.export" will actually download the file. I want a link to download the file, later. This was possible in v2 by means of the exportLinks.
How can I in v3 accomplish the same? If it is not possible, why was this useful feature removed?
Besides, (similar problem to above) downloadUrl was also removed, and the suggested alternative ("files.get with ?alt=media") downloads the file instead of providing a download link. This means there is no way in v3 to get a public short lived URL for a file?
EDIT:
there is no way in v3 to get a public short lived URL for a file?
For regular files, apparently yes.
This seems to work fine (a public short lived link to the file with its right name and contents):
https://www.googleapis.com/drive/v3/files/ID?alt=media&access_token=TOKEN
For google apps files, no (not even private, as v2 exportLinks used to be).
https://www.googleapis.com/drive/v3/files/ID/exportmimeType=TYPEv&access_token=TOKEN
Similar to regular files, this URL is a short lived link to the file contents, but lacking of its right name.
BTW, I see the API is not behaving consistently: /drive/v3/files/FILEID delivers the right file name, but /drive/v3/files/FILEID/export does not.
I think the API itself should be setting the right Content-Disposition, as it is apparently doing when issuing a /drive/v3/files/FILEID call.
This file naming problem invalidates the workaround to the lack of ExportLinks in v3.
The v2 ExportLinks allowed me to link a file (which is not the same as getting its content right away). Anyone logged in and with the proper permissions was able to access it, and the link didn't needed any access_token, and it wasn't short lived. It was good and useful.
Building a link with a raw API call like /drive/v3/files/FILEID/export (with mandatory access_token) would be an close enough workaround (it is temporary and public, not the same as it was, anyway). However, the naming problem invalidates it.
In v2, regular files have a WebContentLink and google apps files have exportLinks. In v3 exportLinks are gone, and I don't see any suitable alternative to them.
Once you query for your file by id you can use the function getWebContentLink() to get the download link of the file (eg. $file->getWebContentLink() ).
I think you're placing too much emphasis on the word "method".
There is still a link to export a file, it's https://www.googleapis.com/drive/v3/files/fileIdxxxxx/export&mimeType=xxxxx/xxxxx. Make sure you URL encode the mime type.
Eg
https://www.googleapis.com/drive/v3/files/1fGBQ81haNU_nEiC5GITZD3bxT0ppL2LHg-C0ubD4Q_s/export?mimeType=text/csv&access_token=ya29.Gmo0BMvO-pVEPKsiD9j4D-NZVGE91MChRvwOcBSg3cTHt5uAClf-jFxcovQScbO2QQhwHS95eSGW1eQQcK5G1UQ6oI4BFEJJkntEBkgriZ14GbHuvpDL7LT2pKA--WiPuNoDDIuZMm5lWtlr
These links form part of the API, so the expectation is that you've written a client that sends authenticated requests, and deals with the response data. This explains why, if you simply paste the link into a browser without an access_token, it will fail. It also explains why the filename is export, ie. it isn't intended that your client would ever use a filename, but rather it should receive the data as a stream. This SO answer discusses the situation in more detail How to set name of file downloaded from browser?
There is a different behavior from Google Drive UI and Google Drive API, when removing a file.
Using Google Drive UI:
remove a file, it will go to trash folder and the Last Modified Date is still the same. (if user restore the file, still there is no change on last modified date)
Using Google Drive API:
delete a file, it will go to trash folder, BUT the Last Modified date is changed and if user restore the file, there will be a new modified date.
to me API behavior is more correct, because there is an action made to the file, therefore modified date should change, but how come Google UI doesn't change the Last Modified date ?
Thanks,
This does appear to be an inconsistency between the UI and the API, although what the correct behavior should be is debatable. I've reached out the engineering team to see if they can bring the two paths inline. In the meantime, you can trash a file without changing the modifiedDate by instead using a Files.patch() request and setting the modifiedDateBehavior parameter to "noChange":
PATCH https://www.googleapis.com/drive/v2/files/...?modifiedDateBehavior=noChange
{
"labels": {
"trashed": true
}
}
We are using the push notifications provided by google Drive API. The change id is pushed to the service by google, and we use the GET Api to retrive the change object. Our requirement is to find from the change object whether it is a file upload/update or trash. We tried using created date, modified date and modification date to find the difference. But the modification date is not providing the time the change happened originally and there is a difference of 2 seconds sometimes.. Also, When a folder is shared to multiple users, for the same change, the modification date which each user receive is different from that of the other and the difference is in seconds.
Please suggest if there is a way to distinguish between file upload/update/trash from change object.
Also, provide inputs on why the modification date is different for each user, and different from file modified date.
NOTE: We cannot use watch for files as per our requirement as there are lot of files in the drive and we can watch only for changes in the entire drive.