Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Scenario

We have a web client that wants to upload files as health data, but we don’t want to build encryption and zip into the web client. As such, we need to enhance Bridge’s upload API to take individual unencrypted, unzipped files as export them to Synapse as health data.

Note that since we need this API in the short term, and since we are planning to deprecate our existing upload APIs when we build Exporter 3.0, we should build a very quick, very targeted solution to this, and we can bake this scenario into Exporter 3.0 as a basic design principle.

Design Overview

We can simply use the existing Upload API, but take in a flag that turns off the decryption and unzip steps of upload handling. In short, the API would look exactly the same as documented in https://developer.sagebridge.org/articles/bundled_zip_file_uploads.html#uploading-your-bundle, but the Upload Request API would take in two additional fields:

encrypted (boolean) - True if the upload is encrypted. False if it is not encrypted. If not specified, defaults to true.

zipped (boolean) - True if the upload is zipped. False if it is a single file. If not specified, defaults to true.

Note that since we aren’t zipping the file, we aren’t including an info.json, which means the new API will have no way of passing in metadata from the client. This has a few consequences:

  • Won’t be able to specify createdOn. This will instead default to the upload time.

  • Won’t be able to specify schema. This is fine, because schemas are not useful for single files, and won’t be supported in Exporter 3.0.

  • Won’t be able to specify appVersion or phoneInfo. Not sure if this matters, since we’re using a web client.

  • Won’t be able to specify custom metadata. Do we need this?

Open Questions

Can the web client generate the content length and MD5 of the file being uploaded? If not, then we’ll need to make these parameters optional and see what (if anything) breaks.

Do we need metadata from the web client, other than participant information already stored on the server?

  • No labels