...

This API will use S3 as the backing store and provide an API to upload and download the files. (S3 Presigned URLs will be used for the actual upload and download.) DynamoDB will be used to index the files, with the participant healthcode as the hash key (EDIT: user ID or health code?) and the file ID as the range key.

...

• This data may contain PHI. We’ll need to secure this endpoint accordingly.

• We probably don’t need versioning for these files.

• Do we need separate create and update APIs for participant files? App developers specifically asked for the ability to specify their own identifiers, and also we don’t do versioning. So both APIs would do the same thing (ie write the file to the index and generate the pre-signed URL).

• Since apps can upload arbitrary files, do we need a virus scanner for these files?

• Do we need an researcher API to view at participant files?

• We may want a worker API to write these files, to enable Bridge Health Data Post-Processing to write these files.

• What kind of indexing do we need on this API? Do we need to view all files for a participant? For a study? For an identifier? If so, considering using SQL to index. (However, if we only have specific indexing concerns, we may want to stick with DynamoDB, as that’s significantly develop against for simple lookups.)

• One possible optimization is to use a streaming API to stream the files through Bridge to/from S3. However, this has its own set of pros and cons.

• Unlike Health Data, we don’t need an “upload complete” API, since we don’t do processing on Participant Files.

REST API