| OTM Bridge Spec |
| Review of Bridge API spec: OTM Bridge API Specification - AssumptionsAssumptions
- 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?
- Version
- specification API or application API?
- 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?
- 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?
- 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
- Restore Status
|
| Next steps |
| Tom - work on Repository Gateway Sepc Bill - updates to OTM Bridge API Specification from discussion Mike - work on DDP/Bridge interaction + put on wiki All - deep thinking about life, liberty, and the pursuit of storing data forever |