Bridge would have a user registered by the DDP in order for the gateway to communicate, can discuss authentication later on
file ids are unique per account – assuming that the gateway/repository has some way of maintaining its own uniqueness. file ids can collide between accounts.
some type of authentication on endpoints - can consider basic auth to start, potentially using tokens instead
some endpoints might not need auth depending on where they are (e.g. getting files from the gateway)
Register
what type of authentication to use - should we do something akin to aws with signed tokens?
basic auth to start?
otm-url to gateway or repository?
gateway
Version
specification API or application API?
s...pecification?
Deposit
is the deposit-id necessary?
no, the bridge could return it in a response. moves responsibility of uniqueness to the bridge + simplifies request body
have been avoiding the question of what constitutes a file, but must ask: what is a file?
a bytestream
are files being grouped in any way?
grouping implies we need to store extra information associated with the files and be able to track that
current spec is simple - just push file identifiers
generally have been trying to avoid describing any grouping abstraction (collection, work, bag, etc), might be best to continue to avoid it
possibly add idea of groupings later
checksum-type is defined at the top level - what about per file?
will expect that all deposits use the same checksum, but can see scenarios where the other might exist
I don't remember where we landed, probably keep this for now and add on later
add endpoint for supported checkpoints?
maybe extend the version api with more information
List Deposits
on lists deposits in progress, intended to provoke thoughts
deposits are seen as an ephemeral resource, not something we will be keeping forever
failed deposits would persist until aborted or restarted
this is something we should continue to dig into and think about
Deposit Status
Abort Deposit
only valid in certain states
need to discuss guarantees from the bridge about what actions it will take depending on where a deposit is
Restart Deposit
similar to abort, just needs to be livened up a bit
Delete Content
are we doing a delete or a purge?
what is the difference?
we can update the endpoint to delete for now, reserve purge for a future version when people have strong opinions about how they want to remove content
what are the error responses/conditions?
checksums not matching, files not existing
how much work do we expect the bridge to do on operations
transferring 10 1tb files could mean certain operations are expensive
even procuring storage
needs more discussion, maybe insight from user stories
when a single file fails, does that fail the entire deletion?
I don't remember
what is the url referring to?
do we need the url? no
do we need the url in the deposit? no - just need to ensure that the gateway has a well defined way of hosting by file identifiers
Delete Status
needs discussion on what the response body is
give per file information?
Get Audit History
file-id not guaranteed to be unique across accounts, maybe we shouldn't use it
could update audit history endpoint to be POST with a request body indicating what files, events you want to receive
allows for good extensibility later on
aligns well with to other endpoints
should this return a response body or an audit-id which the audit events can be received from?
depending on how much is being asked the operation could take some time. could easily trigger timeouts, etc.
if we push to an audit-id, we need to have an idea of how long that resource would last
other events are ephemeral, is this too?
need additional endpoint if we do this
Restore Content
do we need the checksum?
maybe optional
gateway might not have any idea of what the checksum is
need additional endpoint to say where the file is located
restore/{restore-id]/{file-id}
if restore-id is unique, should not need to worry about collisions
