Register/Ingest a Metadata Record with Metadata Document

The following example shows the creation of the first metadata record and its metadata only providing mandatory fields mentioned above:

metadata-record4json.json:
{
    "relatedResource": {
        "identifier": "anyResourceId",
        "identifierType": "INTERNAL"
    },
    "schema": {
        "identifier": "my_first_json",
        "identifierType": "INTERNAL"
    },
    "schemaVersion": 1
}

metadata.json:
{
  "title": "My first JSON document"
}

The schemaId used while registering metadata schema has to be used to link the metadata with the approbriate metadata schema.

$ curl 'http://localhost:8040/api/v1/metadata' -i -X POST \
    -H 'Content-Type: multipart/form-data' \
    -F 'record=@metadata-record4json.json;type=application/json' \
    -F 'document=@metadata.json;type=application/json'

You can see, that most of the sent metadata schema record is empty. Only schemaId and relatedResource are provided by the user. HTTP-wise the call looks as follows:

POST /api/v1/metadata HTTP/1.1
Content-Type: multipart/form-data; boundary=6o2knFse3p53ty9dmcQvWAIx1zInP11uCfbm
Host: localhost:8040

--6o2knFse3p53ty9dmcQvWAIx1zInP11uCfbm
Content-Disposition: form-data; name=record; filename=metadata-record4json.json
Content-Type: application/json

{"id":null,"pid":null,"relatedResource":{"id":null,"identifier":"https://repo/anyResourceId","identifierType":"URL"},"createdAt":null,"lastUpdate":null,"schema":{"id":null,"identifier":"my_first_json","identifierType":"INTERNAL"},"schemaVersion":1,"recordVersion":null,"acl":[],"metadataDocumentUri":null,"documentHash":null}
--6o2knFse3p53ty9dmcQvWAIx1zInP11uCfbm
Content-Disposition: form-data; name=document; filename=metadata.json
Content-Type: application/json

{
"title": "My first JSON document"
}
--6o2knFse3p53ty9dmcQvWAIx1zInP11uCfbm--

As Content-Type only ‘application/json’ is supported and should be provided. The other headers are typically set by the HTTP client. After validating the provided document, adding missing information where possible and persisting the created resource, the result is sent back to the user and will look that way:

HTTP/1.1 201 Created
Location: http://localhost:8040/api/v1/metadata/6785ad43-9a17-40b5-9653-220a8232ef2f?version=1
ETag: "558661553"
Content-Type: application/json
Content-Length: 691

{
  "id" : "6785ad43-9a17-40b5-9653-220a8232ef2f",
  "relatedResource" : {
    "identifier" : "https://repo/anyResourceId",
    "identifierType" : "URL"
  },
  "createdAt" : "2022-05-20T09:54:03Z",
  "lastUpdate" : "2022-05-20T09:54:03.45Z",
  "schema" : {
    "identifier" : "http://localhost:8040/api/v1/schemas/my_first_json?version=1",
    "identifierType" : "URL"
  },
  "schemaVersion" : 1,
  "recordVersion" : 1,
  "acl" : [ {
    "id" : 3,
    "sid" : "SELF",
    "permission" : "ADMINISTRATE"
  } ],
  "metadataDocumentUri" : "http://localhost:8040/api/v1/metadata/6785ad43-9a17-40b5-9653-220a8232ef2f?version=1",
  "documentHash" : "sha1:97ac2fb17cd40aac07a55444dc161d615c70af8a"
}

What you see is, that the metadata record looks different from the original document. All remaining elements received a value by the server. In the header you’ll find a location URL to access the ingested metadata and an ETag with the current ETag of the resource. This value is returned by POST, GET and PUT calls and must be provided for all calls modifying the resource, e.g. POST, PUT and DELETE, in order to avoid conflicts.

« PREVIOUS	NEXT »