Understanding NAS Bridge resources and objects

The NAS Bridge management API allows multiple instances of each REST resource type to exist concurrently. Each instance can be viewed as a type of object. Therefore, for a given resource type, you can consider the resource instances to be an array of one or more objects. This design gives you better flexibility and control when accessing the resource instances through the API.

Object identifiers

Each resource instance or object is assigned a unique identifier. These object identifiers (IDs) are integer values assigned to the new resource instances. The IDs are unique within a specific resource type, but not within the system as a whole. For example, if you create a DNS server, the first instance might be assigned ID=1. Subsequently, you might create an NTP server and the first instance might also be assigned ID=1. This is acceptable because the resource instances are differentiated according to their type.

The identifiers are generally returned in the HTTP response after a successful add request. You can extract and retain the IDs. An ID must be provided in the following situations:

• When getting the current status of a resource instance
• When linking resource instances where one object refers to another
• When deleting a resource instance

Summary of resource statuses

Each resource instance has an associated status. In general, a resource’s status can be accessed and displayed through the management API.

The following status values are used for the NAS Bridge resources:

• NOTIFYING

  The underlying services are being notified of the change.

• COMMITTING

  The underlying services are coordinating the commitment of the change.

• ABORTING

  The change has been rejected. Check the error log messages for more information.

• FAILED

  The change failed and all services have completed a rollback. You should check the system event log for more information.

• READY

  The change has been successful completed, and the resource is ready for use.

In most cases, the original request or action type is added to the beginning to create the complete state description. For example, after issuing an add request, the new resource might temporarily be in the state: ADDING / NOTIFYING. A similar construction applies when removing resources.