Relevant Issue: https://sagebionetworks.jira.com/browse/PLFM-4253
StorageLocationSettings are immutable and thus can be cached client side. The information in these will therefore not be repeated in the new implementations of UploadDestination and FileHandle.
The keyPath in ClientDelegatedS3UploadDestination is client generated: baseKey/<<UUID>>.
The key in ClientDelegatedS3FIleHandle, once uploaded will be baseKey/<<UUID>>/fileName.
The Interfaces exist for future comparability in case we need to add other client reliant storage solutions
New API
Because the upload must occur client-side, the client must be responsible for creating the FIleHandle once uploading has completed
| Action | URI | Method | Request Body | Response Body |
|---|---|---|---|---|
| Creates a ClientDelegatedS3FileHandle. Its storageLocationId must match that of a ClientDelegatedS3StorageLocationSetting | /externalFileHandle/clientS3???? | POST | ClientDelegatedS3FileHandle | ClientDelegatedS3FIleHandle |
The backend only stores this information. I cannot perform many validity checks because the Synapse backend does not have access to the bucket. The only check it could do is ensure that the storagelocationid in the FileHandle is that of a ClientDelegatedS3StorageLocation
Unanswered questions/other thoughts
There's probably a better name for these classes.
Should we also make ExternalFileHandle and ExternalUploadDestination subclasses of ClientDelegatedFileHandleInterface and ClientDelegatedUploadDestinationInterface, respectively?
Make baseKey default to userId if not specified?