...
- 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.
...