...

Bridge API

Bridge API - Endpoints

...

for general use

Bridge Details

• Provides information about the bridge application. Can also be used to verify that the bridge application is available at the expected URL.
• Request: GET /bridge

• Response Body: JSON 

  Code Block
  { "bridge-version" : "", "supported-checksum-types" : "" # Possible values: MD5, SHA-256, SHA-512 }

  
  

• Response Code: 200 (on success)

Bridge API - Endpoints to be used by OTM Gateway

Register

• Purpose: Allows a repository with an OTM API to register itself with the Bridge. The information provided in this registration will allow the Bridge to make calls back to the OTM Gateway, such as to pull content listed in a deposit request. This call must be made prior to calls to deposit content. This call may also be made to update the Gateway information.
• Request: POST /bridge/register

• Request Body: JSON 

  Code Block
  language js
  { "gateway-url" : "", # Endpoint URL where the Bridge can call back to this OTM API "gateway-username" : "", # Credentials to allow the Bridge to make calls back into the OTM API "gateway-password" : "" # Credentials to allow the Bridge to make calls back into the OTM API }

  
  

• Response Code: 200 (on success)
• Notes:
  • In the event that Gateway information is updated by calling this endpoint again, will those changes be applied to existing or in-process deposit requests?

...

• Purpose: Retrieves a listing of all in-process deposits
• Request: GET /bridge/deposit ? {status}
  • status: (Optional) Limit list to deposits in a specific status

• Response Body: JSON 

  Code Block
  {

  Response Body: JSON 

  Code Block
  { "deposit-id-1" : { "files" : "", # Number of files in deposit "status" : "" # Current deposit status }, # Additional deposits listed here }

  
  

• Response Code: 200 (on success)
• Notes:
  • Used by both the OTM Gateway (to check on submitted deposits) and the DDP (to determine if there are deposits which are ready for processing)
  • The deposits returned by this method are only those that are in-process (possibly including those that have recently completed). There is no expectation that information about deposits that have completed successfully or were aborted will be available as part of this call indefinitely, as the deposits themselves are not intended to be the item of record. Information about files in completed deposits can be found by requesting an audit history report (below). Are there use cases that would require longer-term access to completed deposits via this endpoint?

Get Deposit Status

• Purpose: Allows the repository to ask for status of a given deposit
• Request: GET /bridge/deposit/{deposit-id}

• Response Body: JSON

  Code Block
  { "deposit-id" : "", "status" : "", # Value based on defined set of known status states # There could be more information here, like an approximate percentage completion of the current step, if known }

  
  

• Response Codes:
  • 200 (on success)
  • 404 (if the provided Deposit ID does not exist in the system)

...

• Purpose: Removes one or more files from DDP storage
• Request: POST /bridge/delete ? {checksum-type}   # Using POST rather than DELETE, allows for deleting multiple files (and is consistent with Restore action)
  • checksum-type: (Optional) if provided, applies to all file checksums (can be one of: MD5, SHA-256, SHA-512). Default is MD5.

• Request Body: JSON 

  Code Block
  { "file-1-id" : "file-1-checksum", # Checksum is optional, can be included to verify correct file is being deleted "file-2-id" : "file-2-checksum" }

  
  

• Response Code: 202 (on success)

• Response Body: JSON 

  Code Block
  { "delete-id" : "" }

  
  

• Notes:
  
  • In the versioning scenario, checksum may be used to select which version to delete. If no checksum is provided can either assume most recent version or all versions.

...

List Deletes

• Purpose: Allows the repository to ask for status of a content delete actionRetrieves a listing of all in-process deletes
• Request: GET /bridge/purge/{delete-id}delete ? {status}
  • status: (Optional) Limit list to deletes actions with a specific status

• Response Body: JSON 

  Code Block
  { "statusdelete-id-1" : ""{ } "files" : "", # Number of files in delete action "status" : "" # Current delete status }, # Additional delete actions listed here }

  
  

• Response Code: 200 (on success)
• Notes:
  • Used by both the OTM Gateway (to check on delete requests) and the DDP (to determine if there are delete requests which are ready for processing)
  • Similar to deposits, delete IDs returned by this method are only those that are in-process.

Get Delete Status

• Purpose: Allows the repository to ask for status of a content delete action
• Request: GET /bridge/delete/{delete-id}

• Response Body: JSON 

  Code Block
  { "status" : "" } # # This could include a top level status or a per-file status (or both)

  
  

• Response Code: 200 (on success)
• Notes:
  • Need to better define the information that would be provided in the status response

Abort Delete - ?

Restart Delete - ?

Request Audit History Report

...

• Purpose: Requests that content be made available for restore
• Request: POST /bridge/restore ? {checksum-type}
  • checksum-type: (Optional) if provided, applies to all file checksums (can be one of: MD5, SHA-256, SHA-512). Default is MD5.

• Request Body: JSON 

  Code Block
  { "file-1-id" : "file-1-checksum", # Checksum is optional, can be included to verify correct file is being restored "file-2-id" : "file-2-checksum" }

  
  

• Response Code: 202 (on success)

• Response Body: JSON 

  Code Block
  { "restore-id" : "" }

  
  

• Notes:
  
  • In the versioning scenario, checksum may be used to select which version to restore. If no checksum is provided most recent version is assumed.assumed.

List Restores - ?

Restore Status

• Purpose: Allows the repository to ask for status of a content restore action
• Request: GET /bridge/restore/{restore-id}

• Response Body: JSON 

  Code Block
  { "status" : "" } # This could include a top level status or a per-file status (or both)

  
  

• Response Code: 200 (on success)
• Notes:
  • It may be useful to provide a listing of the files that can be retrieved based on this restore request in the response (not assuming that the original requester of the restore kept that list around from the initial call).
  • Restored content will only be made available on the Bridge for a limited time. After this time, content will be removed and the status of the restore will be changed to expired.

Abort Restore - ?

Restart Restore - ?

Get Restored Content

• Purpose: Allows the repository to retrieve restored content from the Bridge
• Request: GET /bridge/restore/{restore-id}/{file-id} ? {checksum-type}
  • checksum-type: (Optional) Defines the type of checksum to be included in the response ETag header. Can be one of: MD5, SHA-256, SHA-512. Default is MD5.

• Response: Restored file content stream

• Response Codes:
  • 200 (on success)
  • 404 (if the file is not part of the restore or the restored content has expired)
• Response Headers: ETag

Bridge API - Endpoints to be used by DDP

Add Account

• Purpose: Allows the DDP to inform the Bridge of a new OTM account. After this call it will be possible for the OTM endpoint to contact the Bridge.

Update Deposit Status

• Purpose: Allows the DDP to inform the Bridge of that a deposit has transitioned to a new OTM account. After this call it will be possible for the OTM endpoint to contact the Bridge.

...

• status. Certain status updates (such as when a deposit is completed) may trigger additional actions within the Bridge.

Update Restore Status

• Purpose: Allows the DDP to inform the Bridge that a deposit has completed and no longer needs to be maintained in staging storage.restore has transitioned to a new status. Certain status updates may trigger additional actions within the Bridge.

Add Audit Events

• Purpose: Update audit index by providing additional audit details

DDP API - Endpoints to be used by the Bridge

Content Ready for Deposit

• Purpose: A set of content is available for deposit
• Dropping this call based on the assumption that the DDP will query the Bridge to determine when new deposits are ready (rather than the Bridge notifying the DDP)