createOdspCreateContainerRequest should have an overload that takes parent item id instead of the parent path

[comanea]

createOdspCreateContainerRequest takes a string folder path and creates a fluid file under it. This can present an issue if users are relying on paths as they can be changed in case any folder along it is moved or renamed. ODSP recommends that OneDrive items are shared by their unique id which mitigates against issues like path localization or folder/file renaming and moving (they are even referenced when they're in the recycle bin).

It looks like the path value is used to construct the api URL at this point in the code where the API follows the pattern drives/[driveid]/items/root/:[destination_folder_path+filename]:/.

A possible solution that can include the destination folder path id is to use the API pattern of drives/[driveid]/items/[parentitemid]/:[filename]:/

An example URL is https://microsoft-my.sharepoint-df.com/_api/v2.1/drives/b!ZXhhbXBsZSBkcml2ZSBpZA/items/ZXHHBXBSZSBMAWXLIGLK/:testfile.fluid:/opstream/?last=1

I'm not sure if the opstream suffix may be required.

Note: b!ZXhhbXBsZSBkcml2ZSBpZA and ZXHHBXBSZSBMAWXLIGLK are not real id's, they're just used to help demonstrate.

[tylerbutler]

@microsoft/fluid-cr-odsp FYI.

[vladsud]

@comanea, I know it's an old issue, but I believe we discussed in other forums. We are not ODSP experts (and that's not where our expertise are), and every team has its own needs when it comes to storage interactions. So, we suggest teams interested in new features to propose draft PRs, ideally with 1-page describing why and how.

[microsoft-github-policy-service[bot]]

This PR has been automatically marked as stale because it has had no activity for 60 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!