Page History

...

• 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?
  • In order to make this call, an account with associated credentials will already need to exist in the Bridge. This will have been created in advance by the DDP (see Add Account below).

Deposit Content

• Purpose: Allows the repository to send content to the Bridge for deposit into the DDP.
• Request: POST /bridge/deposit ? {checksum-type}
  • checksum-type: (Optional) Applies to all file checksums (can be one of: MD5, SHA-256, SHA-512). Default is MD5.

• Request Body: JSON 

  Code Block
  language js
  { "filegroup-1-id" : { # filegroup is a generic grouping of files that can be used to capture structure such as in a digital object or work "file-1-id" : "file-1-checksum", "file-2-id" : "file-2-checksum" }, "filegroup-2-id" : { "file-3-id" : "file-1-checksum", "file-4-id" : "file-2-checksum" } }

  
  

• Response Code: 201 (on success)

• Notes:

  • Each filegroup in the request body is considered an independent deposit which can be referred to in subsequent requests by the filegroup identifier.
  • There is an explicit expectation that the content to be deposited will be available from the OTM Gateway at the path: "gateway-url" + / + "file-id". How the Gateway resolves the file stream based on a request to this URL is irrelevant to the Bridge.
  • Provided Filegroup IDs and File IDs must be URL-safe to support the Bridge requesting those files from the OTM Gateway and the reverse in the restore context

  • There is no guarantee that all filegroups in a single deposit request will be deposited into the DDP at the same time. This allows the Bridge to manage transfers based on available resources (so as to not over-run local disk, for example).

  • This does not currently allow for deposits where files use differing checksum types. Is this a necessary use case?

...

• 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

...

Get Audit History

...

• Purpose: Asks that Retrieves an audit history report be generated. If a set of File IDs are provided, the . The report will list audit events associated with those files. If a set of filegroup, restore, or delete IDs are provided, those will each be resolved to a set of File IDs and those files will be in the resulting reporta single file or set of files in a filegroup.
• Request: POST GET /bridge/audit/{id} ? {id-type}
  • id: The identifier of the filegroup or file for which an audit report is requested
  • id-type: (Optional) Specifies that the type of ID provided in the request body. All IDs must be of the same typespecified ID is either a file or filegroup. Allowed values are: filegroup , or file, restore, or delete. Default value is file.
• Response Codes:
  • 200 (on success)
  • 404 (if there is no audit information for the provided ID)

• Response Request Body: JSON 

  Code Block
  { "idfile-1", "id-2", ... }

• Response Code: 202 (on success)

• Response Body: JSON 

  Code Block
  { -id" : { "audit-reportevent-id1", : "audit-event-2", }, }

  
  

• Notes:
  • It may be possible to discern the type of an ID (as being either a file or filegroup), in which case that id-type parameter is unnecessary.
  • Given that the primary unit of preservation is the filegroup, should
  Given that the primary unit of preservation is the filegroup, should
  • this call be limited to requesting history about
  filegroups? That limit may be sufficient to allow this call to provide a synchronous response.

Get Audit History Report

...

Response Body: JSON 

{
  "file-1-id" : {
    "audit-event-1",
    "audit-event-2",
  },
}

...

• 200 (on success)
• 404 (if there is no audit report with the provided ID)

...

• Events associated with a deposit, restore, or delete should include the appropriate deposit, restore, or delete ID as part of the audit event
• A format for audit events will need to be defined to support processing of these events.
• Audit reports will be retained by the Bridge for some pre-defined length of time (TBD), after which they will be purged and a new report request would be required

• • a filegroup?

Bridge API - Endpoints to be used by DDP

Add Account

• Purpose: Allows the DDP to create a new depositing user account in the Bridge. After this call it will be possible for the OTM Gateway to register with the Bridge. This call can also be used to reset the access credentials for an account.
• Request: POST /bridge/account/{account-name}
  • account-name: The name associated with an account
• Response Code: 201 (on success)

• Response Body: JSON

  Code Block
  language js
  { "account-name" : "", # Name of the account "account-username" : "", # Credentials to allow calls to the Bridge for this account "account-password" : "" # Credentials to allow calls to the Bridge for this account }

  
  

List Accounts

• Purpose: Allows the DDP to list all accounts known by the Bridge
• Request: GET /bridge/account
• Response Code: 200 (on success)

• Response Body: JSON

  Code Block
  language js
  { "account-1-name", "account-2-name" }

  
  

Complete Deposit

Bridge API - Endpoints to be used by DDP

...

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

...

• that a deposit has completed.
• Request: POST /bridge/deposit/{filegroup-id}
• Response Code: 200 (on success)

Complete Restore

• Purpose: Allows the DDP to inform the Bridge that a deposit has transitioned to a new 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 restore has transitioned to a new status. Certain status updates may trigger additional actions within the Bridge.

Add Audit Events

• restore has completed.
• Request: POST /bridge/restore/{restore-id}
• Response Code: 200 (on success)

Add Audit Event

• Purpose: Update audit index by providing additional audit details
• Request: POST /bridge/audit/{id}
  • id: The identifier for the file or filegroup to which this audit event is to be applied

• Request Body: JSON 

  Code Block
  { "audit-event" }

  
  

• Response Code: 200 (on success)
• Notes:
  • Rather than a direct call from the DDP to the Bridge, this could be implemented as a notification stream to which the Bridge is listening.
  Purpose: Update audit index by providing additional audit details