Versions Compared

Old Version 15

changes.mady.by.user Bill Branan

Saved on

compared with

New Version 16

changes.mady.by.user Bill Branan

Saved on

Key

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

...

  • 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
    {
  "filegroup-1-id" : {
    "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)
  •   },                                     # Additional filegroups listed here
}


  • 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.
    • It would be possible to retain enough information to be able to provide a tombstone-type response for File IDs which were at some point in the system but have been removed.

    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.
    • It would be possible to retain enough information to be able to provide a tombstone-type response for File IDs which were at some point in the system but have been removed.
    • Given that the primary unit of preservation is the filegroup, should deletes occur at the filegroup level rather than the file level? This would make the delete action more consistent with the deposit action and would remove the need to mint and manage delete IDs.
    • Is there any reason/need to specify the Filegroup for each file to be deleted? 

List Deletes

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

  • Response Body: JSON 

    Code Block
    {
  "delete-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)
    • Delete IDs returned by this method are only those that are in-process.

...

  • 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
    {
  "filegroup-1-id" : {
  
  "file-1-id" : "file-1-checksum",     # Checksum is optional, can be included to verify correct file is being restored
    "file-2-id" : "file-2-id" : "file-2-checksum"-checksum"
  },                                     # Additional filegroups listed here
}


  • Response Code: 202 (on success)

  • Response Body: JSON 

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

    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.
    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.
    • Should restores occur at the filegroup level rather than the file level? This could remove the need for minting restore IDs.
    • Given that the primary unit of preservation is the filegroup, should restores occur at the filegroup level rather than the file level? This would make the restore action more consistent with the deposit action and would remove the need to mint and manage restore IDs.
    • Is there any reason/need to specify the Filegroup for each file to be restored?

List Restores

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

  • Response Body: JSON 

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


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

...