Versions Compared

Old Version 27

changes.mady.by.user Bill Branan

Saved on

compared with

New Version 28

changes.mady.by.user Bill Branan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.
    • deposit-format: (Optional) Format of content being deposited

  • Request Body: JSON 

    Code Block
    languagejs
    {
  "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
    "version" : "",
    "files" : {
      "file-1-id" : "file-1-checksum",
      "file-2-id" : "file-2-checksum"
    }
  },
  "filegroup-2-id" : {
    "version" : "",
    "files" : {
      "file-3-id" : "file-3-checksum",
      "file-4-id" : "file-4-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" + / "filegroup-id" +/ + "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).

    • The Bridge and DDP will consider the version value as opaque and not attempt to assign any meaning to the value.
      • Not including "version" in the JSON is acceptable and is functionally the same as "version" : "". This "empty" version is equivalent to any other version.
      • Attempting to deposit a filegroup with a filegroup ID and version that both match a previous deposit will be considered an error and rejected
      • When new filegroup versions are deposited, the Bridge may choose to retrieve and submit to the DDP only those files which have changed between versions (based on file ID and checksum).
    • The deposit-format parameter allows the depositor to specify the format of the content being deposited. The Bridge implementation may only support deposits of certain types.
      • Agreements between the depositor and the DDP should specify which types are to be used for deposit.

List Deposits

  • 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
    {
  "filegroup-1-id" : {
    "version : "",       # Version identifier of filegroup
    "files" : "",        # Number of files in deposit
    "status" : ""        # Current deposit status
  },                     # Additional filegroups listed here
}


  • Response Code: 200 (on success)
  • Notes:
    • List requests made by a depositor will return only those deposits which were initiated by that depositing entity
    • List requests made by the DDP (to determine if there are deposits which are ready for processing) will return results for all depositors
      • It may be useful to include a depositor query parameter to allow the DDP to limit the response based on depositor
    • This list will grow large if many deposits are initiated at once and may require paged results
    • This list will not include all historical deposits, but only those that are in the process of being deposited

...