Work in progress
Background & Motivation
See Meredith Slota (Unlicensed)'s 1-pager and the epic Issue:
PLFM-4063 - Getting issue details... STATUS
In summary:
- It is necessary for us to transition to a new DOI provider
- Plan and roles (for example, does UI need to know when we switch/ coordinate that)
- who is currently using the current API?
- We should overhaul how we handle asynchronous requests to manage a DOI to match how we handle other asynchronous requests
- We should implement better ways to handle the collection and submission of metadata (for both practical utility for Synapse users/the scientific community, and compliance with the new provider's standards)
Existing API
Current API can be maintained in the short-term but we should consider deprecating in favor of proposed replacements.
URL | HTTP Type | Description | Response Object |
|---|---|---|---|
| /entity/{id}/doi | PUT | Creates a DOI for the specified entity. The DOI will associated with the most recent version where applicable. | Doi |
| /entity/{id}/version/{versionNumber}/doi | PUT | Creates a new DOI for the specified entity version. | Doi |
| /entity/{id}/doi | GET | Gets the DOI status for the specified entity. | Doi |
| /entity/{id}/version/{versionNumber}/doi | GET | Gets the DOI status for the specified entity version. | Doi |
Proposed API Changes
In addition to the preexisting API:
| URL | HTTP Verb | Description | Response Object |
|---|---|---|---|
| /entity/{id}/doi/async/start | POST | Start a DOI creation job that will attempt to register a DOI with the DOI provider. Note: The caller must have the ACCESS_TYPE.UPDATE permission on the Entity to make this call. | |
| /entity/{id}/doi/async/get/{asyncToken} | GET | Asynchronously get the results of a table update transaction started with POST /entity/{id}/doi/async/start Note: When the result is not ready yet, this method will return a status code of 202 (ACCEPTED) and the response body will be a AsynchronousJobStatus object. |
Note: the Doi object has a DoiStatus field, need to evaluate how that should be handled with asynchronous workers
Questions
Should we force users to provide required metadata to mint a DOI?
Mockups
TBD
Internal Design/Implementation Notes
When we retrieve DOI data for existing Synapse entities (published to Datacite through EZID), the metadata is compliant with Datacite Schema 2.2 (the most recent version is 4.1). We can leave these alone, and force users to supply the metadata required to be compliant with 4.1 if they want to update the info