Hi,
I've recently rewritten our Dropbox consumer to implement the v2 API, instead of v1, following the migration guide's indications.
I was content to see that Dropbox now has a notion of file IDs (as opposed to paths only), as I found it troublesome in the past to work with file paths in file-sharing scenarios. Our app contains multiple cloud storage integrations beside Dropbox and we do not rely on the implicit shareable links that each cloud storage provides, but construct our own hyperlinks instead based on file IDs. In scenarios where the path to the same file was not the same in two users' Dropbox, things became more difficult (i.e. a need to search for the filename, which could be located at root level or in any of the internal folder in the hierarchy). I wanted to use IDs instead of paths, but I noticed that only certain API endpoints support IDs or REVs, while others, such as "/2/files/upload" only accept a path. Therefore it is impossible to overwrite a file for which the ID alone was stored. I would like to understand whether this is by design, as I find it to be inconsistent and kinda beats the purpose of relying on file IDs, which seemed like a great change brought by v2.
Thanks,
Crina
