REST API v1

Authentication

Authentication is via a proxy or delegated model, where the REST client is treated as an administrative user by the Registry. The client, where appropriate, indicates which target subject it wishes to act on behalf of.

The REST client is authenticated via a simple user/password pair transmitted over HTTPS as part of a basic auth transaction. More sophisticated authentication mechanisms, such as delegated SAML assertions, may be supported in the future.

Note: POST may work for edit due to default CakePHP functionality but is not supported.

Adding a New API User (Registry v3.3.0 and later)

As of Registry v3.3.0, there are three types of API Users:

• Platform API Users: API Users created within the COmanage CO are given full access to the API, across all COs.
• Privileged CO API Users: API Users created within any other CO may be designated as Privileged, in which case they will have full access to the API within their CO.
• Unprivileged CO API Users: API Users not designated as Privileged will not have any access to the API by default, but may be granted specific access where supported, for example within a specific plugin.

API Users can be managed by a CO Administrator via CO >> Configuration >> API Users. Platform API Users are created the same way, via the COmanage CO.

API Users must have usernames prefixed with the name of the CO, followed by a dot. For example: MyCO.apiuser 

Self-selected passwords are no longer supported for API Users. Instead, after the API User is created an API Key may be randomly generated. The API Key will be displayed once after generation, but is then hashed for internal storage and is unrecoverable. A new API Key can be generated if needed.

It is also possible to attach validity dates to API Users, as well as to constrain access to specific IP Addresses (via regular expressions). Note there is no current reporting or notification mechanism to indicate the approach of an API User's expiration.

Adding a New API User (Earlier Versions)

Platform Administrators may add and manage API Users via Platform >> API Users.

Note that the API User Name must not conflict with any login identifier for any valid user on the platform. This will be enforced when an API User Name is added or edited, but not currently at any other point. (ie: It is possible for a subsequently added person to have a login identifier that conflicts with an API User Name.) (CO-104)

It may make sense to, by policy, only allow login identifiers in eppn format (with an @) and to only allow API User Names not in that format (without an @).

Object Formats

The REST API supports different formats for representing data object passed. Each format may convey the following special variables:

• Object Type: The type of object represented in the request, as defined for each data type.
• Object Version: The version of the object represented in the request, as defined for each data type.

URL

For methods such as GET that pass arguments as part of the URL, arguments are positional as defined for each data type.

JSON

This format is supported for requests and responses.

XML

This format is supported for requests and responses.

VOOT

This format is experimental. See VOOT API for more information.

Request and Response Formats

Timezones

All times processed (inbound and outbound) via the REST API are in UTC. For more information on timezones, see Understanding Registry Timezones.

API Reference

Sample Clients

See REST API Examples.