Register a schema

A Research Data Repository Service for Managing Metadata Documents based on JSON or XML.

Register a schema

The following example shows the creation of the first json schema only providing mandatory fields mentioned above:

schema-record4json.json:
{
  "schemaId" : "my_first_json",
  "type" : "JSON"
}
schema.json:
{
  "$schema": "http://json-schema.org/draft/2019-09/schema#",
  "$id": "http://www.example.org/schema/json",
  "type": "object",
  "title": "Json schema for tests",
  "default": {},
  "required": [
      "title"
  ],
  "properties": {
    "title": {
      "$id": "#/properties/string",
      "type": "string",
      "title": "Title",
      "description": "Title of object."
    }
  },
  "additionalProperties": false
}
$ curl 'http://localhost:8040/api/v1/schemas' -i -X POST \
    -H 'Content-Type: multipart/form-data' \
    -F 'schema=@schema.json;type=application/json' \
    -F 'record=@schema-record4json.json;type=application/json'

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

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

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

{
    "$schema": "http://json-schema.org/draft/2019-09/schema#",
    "$id": "http://www.example.org/schema/json",
    "type": "object",
    "title": "Json schema for tests",
    "default": {},
    "required": [
        "title"
    ],
    "properties": {
        "title": {
            "$id": "#/properties/string",
            "type": "string",
            "title": "Title",
            "description": "Title of object."
        }
    },
    "additionalProperties": false
}
--6o2knFse3p53ty9dmcQvWAIx1zInP11uCfbm
Content-Disposition: form-data; name=record; filename=schema-record4json.json
Content-Type: application/json

{"schemaId":"my_first_json","pid":null,"schemaVersion":null,"label":null,"definition":null,"comment":null,"mimeType":null,"type":"JSON","createdAt":null,"lastUpdate":null,"acl":[],"schemaDocumentUri":null,"schemaHash":null,"doNotSync":true}
--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/schemas/my_first_json?version=1
ETag: "1855465506"
Content-Type: application/json
Content-Length: 460

{
  "schemaId" : "my_first_json",
  "schemaVersion" : 1,
  "mimeType" : "application/json",
  "type" : "JSON",
  "createdAt" : "2022-05-20T09:54:01Z",
  "lastUpdate" : "2022-05-20T09:54:01.89Z",
  "acl" : [ {
    "id" : 1,
    "sid" : "SELF",
    "permission" : "ADMINISTRATE"
  } ],
  "schemaDocumentUri" : "http://localhost:8040/api/v1/schemas/my_first_json?version=1",
  "schemaHash" : "sha1:98741f0d6115474ab69375be3bc9cd5b305ce200",
  "doNotSync" : true
}

What you see is, that the metadata schema record looks different from the original document. All remaining elements received a value by the server. Furthermore, you’ll find an ETag header 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 »