Schema

The REST Server API uses JSON syntax as the default message format. To use XML, specify the following HTTP request headers.

• Content-Type - to denote the Media-Type of the body you sent to the server.
• Accept - to specify the Media-Type that your client application supports.

On response, the Rest Server API includes a Content-Type HTTP header to specify the type of the returned body, if any. If the type is not explicitly specified in the Content-Type header, the UTF-8 is used for encoding of the body.

Content definition

Each custom XML Media-Type (ending with +xml) the REST API uses is defined using one or more XML schema documents. The corresponding JSON Media-Types (ending with +json) reuses the same schema, which is defined for the XML. The following table describes the XSD documents corresponding to each Media-Type:

Polymorphism with JSON

The XML schema defines XML Types that inherit from each other. This schema is useful when defining XML Type hierarchies by using only the base XML Types. In the JSON, an object carries no additional information about the type. The REST Server API requires the property "@type" to specify type of JSON object.

XML content for starting a ConfigInstance

<startCI xmlns="http://www.ibm.com/xmlns/prod/tdi/72/api" 	
configRef="http://localhost:1098/rest/config/e%3AReadFile"
	keepAlive="true"
	password="myConfigPasswd"
	runName="ReadFile_1">
	<logListner>
		<pollChannel waitTimeout="60" batchCap="1" />
	</logListener>
</startCI>

In this example, the request is for an existing configuration to be started with a new runName and to stay alive when completed. Also, requesting to attach a LogListener when starting the ConfigInstance. The listener uses the Poll Channel that buffers messages on the server side until they are requested by the client. Te actual date is represented in JSON format as shown in the following example.

{
"configRef" : "http://localhost:1098/rest/config/e%3AReadFile",
"keepAlive" : true,
"password" : "myConfigPasswd",
"runName" : "ReadFile_1",
	"logListner" : {
		"@type" : "logListener",
		"channel" : {
			"@type" : "pollChannel",
"waitTimeout" : 60,
"batchCap" : 1
}
}
}

The syntax is same as defined in the api/configuration.xsd. However, there are two additional occurrences of the "@type" property, which are not specified by that XSD document.

The"@type" : "logListener" property is specifying that the object is of the same type as the global XML element name ""logListener"". The property name specifies the base type of the property ("LogListener").

On the next "@type" property, you can see that the "channel" property is the local element name and the type is pointing to a base type (the abstract "TransportChannel"). Use the global XML element name as defined in the corresponding XSD ("pollChannel") to specify the type to be used.

There is no "@type" property in the root object. The type of root object is deduced by the operation being started. However, you can use the HTTP Request header "Content-Type" to specify the type of object you are sending. The value of the header is "application/com.ibm.di.api.configuration+json;type=startCI". For type, the global element name is used as defined in the corresponding XSD document.