...
- 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 "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).
- This does not currently allow for deposits where files use differing checksum types. Is this a necessary use case?
- The version attribute was added as part of the JSON body on 2019-09-06
- Not including "version" in the JSON is acceptable and is functionally the same as "version" : "". This "empty" version is equivalent to any other version.
- The Bridge and DDP will consider the version value as opaque and not attempt to assign any meaning to the value.
- Attempting to deposit a filegroup with a filegroup ID and version that both match an a previous deposit will be considered an error and rejected
...
- 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" : { "version" : "", "files" : { "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" } }, # 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.
- The version attribute was added as part of the JSON body on 2019-09-06-09-06.
- It would be possible to allow the "files" section to be omitted if all files in a given filegroup version are to be deleted.
- It would be possible to allow the value associated with a filegroup ID to be omitted if all files in all versions of a filegroup are to be restored.
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" : { "version" : "", "files: { "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" } }, # Additional filegroups listed here }
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.
- The version attribute was added as part of the JSON body on 2019-09-06
- It would be possible to allow the "files" section to be omitted if all files in a given filegroup version are to be restored.
- It would be possible to allow the value associated with a filegroup ID to be omitted if all files in all versions of a filegroup are 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.
...