Google Drive - Changes:list API - Detect changes at folder level

Question

I'm testing out Google Drive 'Changes' API and have some questions.

Expectation: I've folder tree structure under 'My Drive' with files in them. I would like to call the Changes:list API to detect if items have been added/edited/deleted within that specific folder id.

APIs Explorer tried: https://developers.google.com/drive/v2/reference/changes/list

Questions:

1. I don't see any option to pass a specific folder id to this API for getting the 'largestChangeId'. Looks like this api doesn't support the parm 'q'? Is it possible?

2. As an alternate solution, thought of storing the 'modifiedDate' attribute for that folder and use it for comparing next time. But, it's not getting updated when items are updated within that folder. Should it not work like in windows where folder modified date gets updated when its contents gets updated?

Would like to hear if it's possible to detect changes at folder level.

Thanks

[EDIT]

Solution that worked:

1. Use Files:list to list all. selected fields: items/id,items/modifiedDate,items/parents/id,items/title

2. Get starting folder id ( e.g for 'MyRootFolder' using Title search)

3. Traverse through the sub-tree structure (linking parents:id and file Id) using recursive array search and get max modifiedDate and total file counts.
4. Store max modifiedDate and file counts in the app storage.
5. For subsequent calls, compare the new max modifiedDate with the stored and also compare total file counts with the stored. If either one doesn't match, then contents within 'MyRootFolder' has been updated.

Answer 1

This is not currently possible directly with the API -- sorry!

I think the best current solution would be to use the regular changes feed and filter results in your code to ones with the correct parents set.

Answer 2

drive.changes.list google drive API now allows users to pass the "startChangeId" parameter.

Im using the value I get for "largestChangeId" from the previous API result, So I can incrementally build the changes done by the user, avoiding the need to rebuild the entire tree.

how ever I'm surprised to see why they don't support the "includeDeleted" parameter together with "startChangeId" parameter.