3. API Extensions Table (Template)

Any API used for integration within a Catalyst or open hack hosting project should reuse TMF APIs or an existing resource REST operation from the existing APIs.

However, for certain scenarios, it may be necessary to extend the API.

When a new API is proposed as an extension of an existing API the extension mechanisms must be compliant with the REST Guidelines and compatible with existing features of the information and data models when they exist.

Extensions of existing APIs includes the following :

• Extension of an existing TMF API Resource Operation for example GET customerAccount from the Customer Management APIs
• Extension of Resource properties. Extended resource properties exposed by the Catalyst API must be compliant with the mandatory set of properties for that entity as defined by the specification (or the conformance profile).
• Extension of existing TMF API notfications. Where the project exposes notifications related to a Resource then the notfications as defined within the related TMF specification must be reused.

Note that extension of an exisitng APIs does not require that the CTK is executed for every mandatory resources or operations of an API. Extension here is focused on extending existing operations or adding new operations to an existing resource. The same apply for notifications when they exist.

For example it is valid to expose GET /customer where the customer resource has been extended to support new proprties or relationships. It is also valid to add directives like .sort to exisiting operations.

The prefered mechanism for extending an API when the Uniform Operations can’t be used is to use the Task pattern.

Use the following table to identify the mapping of the Catalyst API’s to TMF API’s and their extensions.

The cells in green are illustrative examples.