I’ve put together a few API’s in various day jobs and if I’ve drawn one conclusion from the process.People can tend to become rather over enthused by the technology whilst possibly loosing sight of the requirement.
Yes it is possible to completely represent the entire functionality of a device over one or a series of end-points and by careful use of RESTful interfaces and MUCH (much, much) security provide an experience that represents the actions of the device, but as with (nearly) all computing you are really only modelling a series of human / mechanical interactions and often the interface looses much subtlety that the original device had.
One could, for example, produce an API to control a Mini Moog but I suspect that for a lot of proficient users it might provide nothing more than a clever way of doing a remote control panel, or a patch library and then how would you deal with the devices control panel when each new patch loads? (hook, current, or replace all the pots with encoders and leds…?) Would it still be the same device after the API had taken over?
The base interaction level of the zynthian is the XWindows based control interface which is both simplistic ( in a good way 
). Certainly it’s got elements above this ( MOD-UI springs to mind) but at the base level we have layers, engines, parameters, snapshots and some house keeping.
You would certainly want to present these, but I would suggest an approach I’ve had some success with.
Using Accessibility techniques.
Trying to define the simplest level of interaction you can provide that will allow you to control the device.
If we can represent the simple 4 knobs and short, medium and long pushes with simple commands ( I’ve always said MIDI ) then the entire interface could be driven by a VERY simple interface that we could operate across continents if we felt so inclined.
That way we have a mechanism that sets the GUI as the base from which the API is constructed and we maintain our user Interface as a controlling device that could be built upon, rather than risking the dangers of the API dragging the original function of the device in directions that might not really address the new desire and damage what has already been done to provide a tightly defined base functionality.