REST API Structure
The URI scheme for accessing a managed object follows this convention, assuming the Identity Cloud web application was deployed at
The URI scheme for accessing a system object follows this convention:
An example of a system object in an LDAP directory might be:
For LDAP resources, you should not map the LDAP
dn to the Identity Cloud
_id). The attribute that is used for the
_id should be immutable. You should therefore map the LDAP
entryUUID operational attribute to the Identity Cloud
_id, as shown in the following excerpt of the provisioner configuration file:
... "uidAttribute" : "entryUUID", ...
Every managed and system object has an identifier (expressed as id in the URI scheme) that is used to address the object through the REST API. The REST API allows for client-generated and server-generated identifiers, through PUT and POST methods. The default server-generated identifier type is a UUID. If you create an object by using
POST, a server-assigned ID is generated in the form of a UUID. If you create an object by using PUT, the client assigns the ID in whatever format you specify.
Most of the examples in this guide use client-assigned IDs, as it makes the examples easier to read.
The REST API fully supports negotiation of content representation through the
Accept HTTP header. Currently, the supported content type is JSON. When you send a JSON payload, you must include the following header:
In a REST call (using the curl command, for example), you would include the following option to specify the noted header:
--header "Content-Type: application/json"
You can also specify the default UTF-8 character set as follows:
--header "Content-Type: application/json;charset=utf-8"
application/json content type is not needed when the REST call does not send a JSON payload.
The REST API supports conditional operations through the use of the
If-None-Match HTTP headers. The use of HTTP conditional operations is the basis of Identity Cloud's optimistic concurrency control system. Clients should make requests conditional in order to prevent inadvertent modification of the wrong version of an object. For managed objects, if no conditional header is specified, a default of
If-Match: * is applied.
|PUT||Update the object if the <rev> matches the revision level of the object.|
|PUT||Update the object regardless of revision level|
|PUT||Create; fails if the object already exists|
|When the conditional operations ||PUT||Upsert; attempts a create, and then an update; if both attempts fail, return an error|