...
We should consider deprecating the DOI creation calls. We could pseudo-maintain until we decide to deprecate by just making the new API calls when these are called.
URL | HTTP Type | Description | Response Object | Notes |
|---|---|---|---|---|
| /entity/{id}/doi | PUT | Creates a DOI for the specified entity. The DOI will associated with the most recent version where applicable. | Doi | Deprecate in favor of corresponding POST |
| /entity/{id}/version/{versionNumber}/doi | PUT | Creates a new DOI for the specified entity version. | Doi | Deprecate, ditto |
| /entity/{id}/doi | GET | Gets the DOI status for the specified entity. | Doi | Maintain, as this will not require a call to another service and should be relatively quick |
| /entity/{id}/version/{versionNumber}/doi | GET | Gets the DOI status for the specified entity version. | Doi | Maintain, ditto |
Proposed API Changes
Object changes:
- Creation of DoiMetadata object
- This object abstracts DataCite's more complex and granular metadata API by including only fields that are required and cannot be automatically populated.
- This object is easily extensible to further support DataCite's metadata schema to include optional fields or the introduction of new required fields
- Doi and DoiMetadata are proposed to be uncoupled because
- We store the data in Doi objects; it allows us to quickly identify if a DOI has been registered and report that to the client
- We do NOT store the data in the DoiMetadata objects; this is stored by the DOI provider and retrieved when necessary
- Caching this data seems unintuitive; retrieving this data should only be expected when a user considers updating it (see notes in table below), which requires the external service to be available anyways.
DataCite-imposed constraints:
- There cannot be more than 8000-10000 creators
- Publication year must be in 'YYYY' format (regex:
/[\d]{4}/) - The creators should be at least 1 character long
- The title should be at least one character long
In addition to the preexisting API:
| URL | HTTP Verb | Description | Request Object | Response Object | Notes |
|---|---|---|---|---|---|
| /entity/{id}/doi/async/start | POST | Asynchronously create or update a DOI. If the DOI does not exist, start a DOI creation job that will attempt to register a DOI with the DOI provider with the supplied metadata. If the DOI does exist, then it will simply update the DOI with the supplied metadata. Note: The caller must have the ACCESS_TYPE.UPDATE permission on the Entity to make this call. | DoiMetadata (application/json) | Shift the work to an asynchronous worker queue (as we have been doing with other asynchronous services). We combine the create and update calls because they require the same information. The workflow for the business logic required to register and update a DOI with DataCite is similar. If no DoiMetadata object is provided, we may choose to submit "N/A" fields (pending discussion on if this is appropriate) | |
/entity/{id}/version/{versionNumber}/ doi/async/start | POST | Ditto; For a specific entity version | DoiMetadata | AsyncJobId | Ditto |
| /entity/{id}/doi/async/get/{asyncToken} | GET | Asynchronously get the results of a DOI 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. | None | After the job completes, this should be identical in function to the existing GET calls. | |
| /entity/{id}/version/{versionNumber}/ doi/async/get/{asyncToken} | GET | Ditto; For a specific entity version | None | Ditto | |
| /entity/{id}/doi/metadata | GET | Get the metadata associated with a DOI Object, if it exists. Note: The caller must have the ACCESS_TYPE.UPDATE permission on the Entity to make this call. | None | DoiMetadata | Can be used to populate the metadata fields of an object that has a DOI, since that data is stored on DataCite. We restrict this to users that can update the data because it should only be used for update purposes; if an unprivileged user wants to retrieve the metadata for an object, they should use the DOI provider's public API. |
Note: the Doi object has a DoiStatus field, we need to evaluate how that should be handled with asynchronous workers (we would probably just deprecate that field in favor of using AsynchronousJobStatus).
...