Traverse Web Services API Workflow

The following describes a typical Traverse Web Services API workflow:

1. Client application uses the Session Manager service to log in to Traverse by providing a username and a password.
2. Traverse sends back a response, including a session identifier (ID). This session identifier can also be shared with the web application.
3. The client application uses the session ID to make calls to Traverse through the different web services. The client application uses the session ID with every call.
4. The client application ends its interaction with Traverse by logging out using the Session Manager service.

Web Services Operations

Depending on login credentials, Traverse exposes a certain set of objects. Each web service operation has the same basic structure:

• They have a single request parameter and they return a response parameter.
• The request objects all have a mandatory session ID along with the rest of the arguments.
• The response objects all have an integer statusCode and statusMessage field. The statusCode should always be checked when receiving a response. A value of 0 indicates success, and any other value is either a warning or error with the description in the statusMessage field.

User Types

The Session Manager service defines three types of users:

• End user - An end user has restricted access to the system. For example, the member of a department.
• Admin user - An admin user has limited administrative access to the system.
• Superuser - A superuser has full access to the system.

Objects in Traverse

The following types of objects are available in Traverse:

• Departments
• Containers
• Network Devices
• Test Configs

Each object is uniquely identified by a serial number, which is a positive 64-bit integer value. While object names can change, the serial number should be used as a key to uniquely identify objects.

Object Severity & Status

The status of the different objects is represented by an integer value: