Rest API Suggestions

During a recent discussion somebody mentioned tests and API’s so could we start to build up a list of API calls and some details of the test that would exercise them?

1/ Restart GUI
GET call
parameter test=False ( not set returns current instance id hash)

returns hash of instance id . . .

Test.
checks for running GUI and records instance id
calls API
checks for running GUI and different hash.

1 Like

2/ List Engines
Get Call
returns list of Engines Available

test compare with expected set.

3/ List Layers
GET Call
returns list of Layers Loaded

Test
Clean Machine ( No default snapshot’) returns 0 layers

4/ Add Layer
POST Call
parameter Engine

test
call List Layers (No default snapshot) assert 0 layers
call List Engines assert expected set
check test engine in set
call Add Layer
check test engine in list

5/ Delete Layer
POST Call
parameter Layer to delete

test
call {Add Layer test body (no TearDown) }
call Delete Layer layer 1
call List Layers
assert 0 layers

6/ Remove All Layers
GET Call

test
call {Add Layer test body (no TearDown) }
call Add Layer test2 Engine
assert Layer count
call Remove all Layers
call List Layers
assert 0 layers

1 Like

Other Resets.

a1/ List Running Engine instances
GET
returns list of active engines with instance ID’s

test
List Running engines on startup.

a2/ All Engine Reset
Get Call (Security :smiley: )
restart default settings

test.

List Running Engine Instances
Restart Engines
List Running Engine Instances
assert differences between instances.

Snapshot

b1/ Load Snapshot
Post
parameter snapshot instance

test
Get layer list
Load Test Snapshot
Get Layer List
Assert change from first list
Assert test Snapshot initial matches Get Layer List

b2/ Save SnapShot
POST
parameter file name

test

Load test snapshot
Get Layer List
Save Snapshot testname

Remove All Layers
Get Layer List
assert difference

Load Snapshot testname
Get Layer List

assert equal

He he - this doesn’t seem to have gone too far!!! What we do have now is CUIA which allows (almost?) complete control of the device via MIDI2CUIA interface. An OSC or other web based interface may be desirable but we can do the control side of things now. We do not have the feedback though, i.e. there is currently no indication to the testing device of the state of the device under test. I do not see CUIA performing such a task whereas OSC may provide a good interface. Other Restful API implementations may be preferred by some of our more web based (dare I say, younger?) contributors but an advantage to using OSC is that it is an interface that has an operational purpose so we may avoid overhead of implementing extra interfaces, i.e. if we implement OSC as an operational feature then we automatically gain it as a test feature.

It is unclear to me where we are with OSC implementation. It seems like it is on the back-burner but maybe we can warm it up again once Aruk is released.

Note that all CUIAs are callable vía OSC:

It’s a first step :wink:

What is the base osc path?

Simply the CUIA “name”. You can check the code here: