wiki:RestAPI

Version 5 (modified by Tom Goddard, 5 years ago) ( diff )

--

Tristan developed a REST API for Phenix to be able to send data to ISOLDE and suggested that ISOLDE be able to call Phenix using the same REST (http request) approach.

Tristan sent a description of his Phenix / ChimeraX communication API to Phenix developers on October 1, 2019. A more recent description is in his Phenix/ChimeraX interaction write-up and duplicated below.

His REST implementation in ISOLDE is part of the ISOLDE Github repository.

RBVI discussed whether his REST API should be included in the standard ChimeraX distribution in our August 29, 2019 developer meeting

REST Interface

I have an initial, working implementation of how I envisage a REST-based interface between ChimeraX and ISOLDE. The code is at https://github.com/tristanic/isolde/tree/master/isolde/src/remote_control/rest_server. The server side can be started with the ChimeraX command “isolde remote rest start port 12345”. The file client.py is a standalone file that should be importable in any Python 2.7 or >=3.6 environment. With ChimeraX running the server, the client connects using something like:

from client import IsoldeRESTClient
port = 12345
ic = IsoldeRESTClient(‘localhost’, port)
ic.connect() # Client class becomes populated with methods defined
             # by the server. These appear as normal Python 
             # methods, with the proviso that arguments must be 
             # JSON-serialisable. The return type is a dictionary
             # that always contains the log contents plus any 
             # method-specific information.

The currently defined server methods are listed at https://github.com/tristanic/isolde/blob/5f65a6f0f958ff23fec0ff81a0c9933f95d0edf5/isolde/src/remote_control/__init__.py#L41 (the actual method definitions are in https://github.com/tristanic/isolde/blob/master/isolde/src/remote_control/server_methods.py). The methods reconstituted on the client side are based on introspection – they have the same signature (minus the initial session argument) and docstring. As an example, continuing on from above:

ret1 = ic.load_model(‘full/path/to/model.cif’)
mid = ret2[‘model’]
ret2 = ic.load_stucture_factors(‘full/path/to/sf.mtz’, mid)
mid = ret2[‘model’] # Shouldn’t have actually changed…
ret3 = ic.update_model_from_file(model, ‘full/path/to/new_model.cif’)
# Closes the existing model, and replaces it with a fresh one

While incomplete, the methods defined here already go a long way towards replicating the existing remote interface between Phenix and Coot, with the improvement that this server actually returns information beyond “success” and “failure”. An obvious extension allowing easy “arms-length” communication between ChimeraX and Phenix would be to run a similar server on the Phenix side allowing ChimeraX to remotely call selected Phenix methods. Another fairly easy improvement might be to switch from JSON to the much more flexible msgpack (I didn’t know about the latter when I wrote this).

Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.