Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: proposed object structure syntax

...

  • 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
    {
      "object-1-id": {
        "file-1-id" : "file-1-checksum",
        "file-2-id" : "file-2-checksum"
      },
      "object-2-id": {
        "file-3-id" : "file-1-checksum",
        "file-4-id" : "file-2-checksum"
      }
    }


  • Response Code: 201 (on success)
  • Response Body: JSON 

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


  • Notes:

    • 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 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 files 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?
    • This does not currently provide a method for grouping files (e.g. to specify all files in a "work"). Is there a need to capture groupings within the Bridge or DDP?

...