Client Application Features

To load or create a micro analytic module, the client application posts a module with a request body that contains the DS2 source code to the module’s resource collection.

The DS2 source code is represented as a source code representation that compiles into one DS2 package. The package is represented as a micro analytic module with multiple methods that are represented as steps in the REST API. Therefore, a module contains multiple steps. These modules and steps are stored in memory. The response body that is returned contains a module resource for the module.

The client application references a step directly by using an ID of the module generated by the REST server. This ID is referred to as the module ID, and the name of the step (compiled DS2 method) is referred to as the step ID.

Before executing the step, the client application performs a GET method on the step to retrieve these signatures:

The client application posts to the step's validations resource, along with a request body that contains the input values that are required to execute the step (compiled DS2 method).

When the POST is received, the input values are validated against the input signature of the step. A validation error is reported to the client as a response body that contains the validation results. This allows the client to validate its input before execution.

The service supports a synchronous way to execute a step (compiled DS2 method). In this case, the client application posts to the step resource, along with a request body that contains the input values that are required to execute the step (compiled DS2 method).

The client application creates a new revision of a module through its module ID.

The client application deletes a module through its module ID.