REST API Reference > Informatica Intelligent Cloud Services REST API > Header and body configuration
  

Header and body configuration

Configure the request header and request body as required, taking into consideration the format of the call and the resource version that you use.

Request header

The request header is slightly different for version 2 and version 3 resources.
For version 2 calls, use the following format in the REST API request header:
<METHOD> <serverUrl>/<URI> HTTP/<HTTP version>
Content-Type: application/<json | xml>
Accept: application/<json | xml>
icSessionId: <SessionId>
For version 3 calls, use the following format in the REST API request header:
<METHOD> <baseApiUrl>/<URI> HTTP/<HTTP version>
Content-Type: application/json
Accept: application/json
INFA-SESSION-ID: <SessionId>
Note that if you use a tool such as Postman, requests automatically include the HTTP version. If you enter the HTTP version in the URL, the request is not successful because the HTTP version occurs twice in the URL.
The following list describes the attributes of the version 2 and version 3 request header formats:
Attribute
Required
Description
METHOD
Yes
Method you want to use, such as GET, POST, or DELETE.
serverUrl
Required for most v2 resources
Base URL for all version 2 resources except login and register.
Use a placeholder for serverUrl, and replace the placeholder with the Informatica Intelligent Cloud Services URL returned by the login resource.
For the login and register resources, use the URL listed in the resource.
baseApiUrl
Required for most v3 resources
Base URL for all version 3 resources except login.
Use a placeholder for baseApiUrl, and replace the placeholder with the Informatica Intelligent Cloud Services URL returned by the login resource.
For the login resource, use the URL listed in the resource definition.
URI
Required for most resources
Resource URI.
The URI includes the base URL and the resource name and can also include parameters.
For the login and register resources, use the URL listed in the resource definitions.
HTTP version
Yes
HTTP version that you are using.
Some tools such as Postman automatically include the HTTP version in the header.
Content-Type
Required for POST requests
Format of the request. Use one of the following options:
  • - application/json. Reads request as JSON.
  • - application/xml. Reads request as XML. Only applicable to version 2 resources.
Default is json.
Accept
No
Request format that you want to receive. Use one of the following options:
  • - application/json. Sends response as JSON.
  • - application/xml. Sends response as XML. Only applicable to version 2 resources.
Default is json.
icSessionId
Required for most v2 resources
Informatica Intelligent Cloud Services session ID. Required for all version 2 resources except login and register.
Use a placeholder for sessionId, and replace the placeholder with the session ID returned by the login resource.
INFA-SESSION-ID
Required for most v3 resources
Informatica Intelligent Cloud Services session ID. Required for all version 3 resources except login.
Use a placeholder for sessionId, and replace the placeholder with the session ID returned by the login resource.

Request body

Use the request body to pass additional attributes for the resource. When you pass attributes in a request body, you pass the attributes as part of an object.
For example, to log in with the login resource, you pass the required username and password attributes in a login object.
Some requests include sub-objects for attributes. Declare the sub-objects before listing the related attributes.

JSON format

When you use the JSON format for version 2 REST API calls, you can optionally define a request object with the @type attribute, as shown in the following examples:
{
"@type": "<request object>",
"<attribute1>": "<value1>",
"<attribute2>": "<value2>",
}
When an attribute includes an object, state the attribute and use the object name as follows:
{
"@type": "<request object>",
"<attribute1>": "<value1>",
"<attribute2>": {
"@type": "<attribute object>",
"<attributeA>": "<valueA>",
"<attributeB>": "<valueB>",}
"@type": "<attribute object>",
"<attributeD>": "<valueD>",
"<attributeE>": "<valueE>",}
"<attribute3>": "<value3>",
}
Note: For version 3 REST API calls, do not use the @type attribute.

XML format

When you use the XML format, define a request object as an enclosing set of tags, as follows:
<request object>
<attribute1>value1</attribute1>
<attribute2>value2</attribute2>
</request object>
When an attribute includes an object, enclose the attribute object within the attribute tags as follows:
<request object>
<attribute1>value1</attribute1>
<attribute2>
<attribute object>
<attributeA>valueA</attributeA>
<attributeB>valueB</attributeB>
</attribute object>
<attribute object>
<attributeC>valueC</attributeC>
<attributeD>valueD</attributeD>
</attribute object>
</attribute2>
<attribute3>value3</attribute3>
</request object>

Return lists

When the REST API returns a series of objects in XML, it encloses the list in the root tag, as follows:
<root>
<return object 1>
<attribute1>value1</attribute1>
<attribute2>value2</attribute2>
</return object 1>
<return object 2>
<attribute1>value1</attribute1>
<attribute2>value2</attribute2>
</return object 2>
</root>
In JSON, no additional attributes are used. The REST API encloses the list in square brackets ( [ ] ), as follows:
[
{
"<attribute1>": "<value1>",
"<attribute2>": "<value2>",
}{
"<attribute1>": "<value1>",
"<attribute2>": "<value2>",
}
]

JSON format example

To log in using JSON, you might use the following request header and body:
POST https://dm-us.informaticacloud.com/saas/public/core/v3/login
Content-Type: application/json
Accept: application/json

{
"username": "user@informatica.com",
"password": "mypassword"
}
The login might return the following information:
{
"products": [
{
"name": "Integration Cloud",
"baseApiUrl": "https://pod.clouddev.informaticacloud.com/saas"
}
],
"userInfo": {
"sessionId": "9KA11tLGqxVcGeul8SQBK3",
"id": "9L1GFroXSDHe2IIg7QhBaT",
"name": "user",
"parentOrgId": "52ZSTB0IDK6dXxaEQLUaQu",
"orgId": "0cuQSDTq5sikvN7x8r1xm1",
"orgName": "MyOrg_INFA",
"groups": {},
"status": "Active"
}
}
You can then use the sessionId and the baseapiUrl to construct a request to obtain your organization's license information, for example:
GET https://pod.clouddev.informaticacloud.com/saas/public/core/v3/license/org/{orgId}
Content-Type: application/json
Accept: application/json
INFA-SESSION-ID: IV4wOrJmd6YUtmKa8t

XML format example

You can use XML calls with version 2 resources.
To log in using XML, you might use the following header and body:
POST https://dm-us.informaticacloud.com/ma/api/v2/user/login
Content-Type: application/xml
Accept: application/xml

<login>
<username>useremail@company.com</username>
<password>mypassword</password>
</login>
The login might return the following information:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user>
<id>00000B03000000000001</id>
<orgId>00000B</orgId>
<name>user@company.com</name>
<createTime>2012-06-14T15:00:00.000Z</createTime>
<updateTime>2012-06-14T15:00:00.000Z</updateTime>
<createdBy>System</createdBy>
<updatedBy>user@company.com</updatedBy>
<firstName>Firstname</firstName>
<lastName>Lastname</lastName>
<title>Senior Software Engineer</title>
<password>********</password>
<phone>11111111111111111111</phone>
<timezone>America/Los_Angeles</timezone>
<serverUrl>http://example.informatica.com/saas</serverUrl>
<icSessionId>IV4wOrJmd6YUtmKa8t</icSessionId>
</user>
You can then use the icSessionId and the serverUrl to construct a request to delete a schedule as follows. The schedule ID is 000001D0000000000001.
DELETE http://example.informatica.com/saas/api/v2/schedule/000001D0000000000001
Accept: application/xml
icSessionId: IV4wOrJmd6YUtmKa8t
Note that Content-Type is not required because the DELETE method does not have additional attributes to pass in the request body.