You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: repository-services/repository-api.md
+52-7
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
This document is to define the interface between the broker and the target repository services.
3
3
This applies to all repositories, including BioSamples.
4
4
5
-
At present, only a single API endpoint is required, `submit`. Authentication and data transfer are not covered in this document, but some assumptions are laid out below.
5
+
There is one required endpoint, `submit`, as well as a submission status endpoint recommended for long-running submission processing. Authentication and data transfer are not covered in this document, but some assumptions are laid out below.
6
6
7
7
## Authentication
8
8
If the repository requires authentication to submit data, the submit endpoint must allow authentication via an authorization header.
@@ -35,24 +35,33 @@ The response must be JSON in the following format:
35
35
"errors": [
36
36
// error objects
37
37
],
38
+
"status": {
39
+
// status object
40
+
},
38
41
"info": [
39
42
// info objects
40
43
]
41
44
}
42
45
```
43
46
where:
44
47
*`targetRepository` is the identifier used to annotate the ISA-JSON and should take values from [identifiers.org](http://identifiers.org/)
45
-
* Either [`accessions`](#accession-object) OR [`errors`](#error-object), but not both, must be present as a list of objects of the form described below. Presence of this field indicates whether the submission was a success or a failure.
46
-
* (optional) [`info`](#info-object) is a list of objects of the form described below. This allows additional repository-specific information to be returned in the response.
48
+
* Exactly one of the following:
49
+
*`accessions`: list of objects defined [here](#accession-object)
50
+
*`errors`: list of objects defined [here](#error-object)
51
+
*`status`: object defined [here](#status-object)
52
+
* Presence of `accession`, `errors`, or `status` indicates whether the submission was a success, failure, or is still pending (asynchronous response).
53
+
* (optional) `info` is a list of objects of the form described [below](#info-object). This allows additional repository-specific information to be returned in the response.
54
+
55
+
This object is frequently referred to as the "receipt" or the "MARS receipt".
@@ -88,6 +97,20 @@ The error objects being returned by the repository may be used by developers to
88
97
89
98
Besides this error reporting, the service should employ other HTTP error codes as usual (e.g. 401).
90
99
100
+
#### Status object
101
+
The status object looks like the following:
102
+
```jsonc
103
+
{
104
+
"statusUrl":"...",
105
+
"id":"...",
106
+
"percentComplete":0.25,
107
+
}
108
+
```
109
+
where:
110
+
*`statusUrl` is a URL that can be queried to determine the completion status of the submission (see [status endpoint](#submission-status-endpoint) section below)
111
+
* (optional) `id` is an identifier for the submission
112
+
* (optional) `percentComplete` is a number between 0 and 1 indicating the approximate percentage of the processing by the repository that is complete
113
+
91
114
#### Info object
92
115
The info object looks like the following:
93
116
```jsonc
@@ -96,10 +119,21 @@ The info object looks like the following:
96
119
"message":"..."
97
120
}
98
121
```
99
-
where `name` and `message` are strings at the repository’s discretion.
122
+
where `name`(optional) and `message` are strings at the repository’s discretion.
100
123
101
124
This can be used to provide any additional information back to the user, not relating to accessions or errors. For example, it could include the submission date and when the data will be made public. This will not be processed further by the broker but will only be presented to the user.
102
125
126
+
## Submission status endpoint
127
+
`GET /{submission_id}/status`
128
+
129
+
(The endpoint path is only a suggestion, the actual path can differ as long as it is accurately returned in the `status` field of the receipt.)
130
+
131
+
This endpoint is used to poll for the status of a previous submission. It should be used whenever the time from data and metadata submission until the issuing of accessions exceeds a reasonable duration, and it must be returned in the `status` field of the receipt.
132
+
133
+
### Response
134
+
135
+
The response must be the same format as for the submit endpoint (i.e. the [MARS receipt](#response)), again indicating whether the submission is complete and successful, complete with errors, or still pending.
0 commit comments