Changes between Version 4 and Version 5 of RestAPI

Timestamp:

Apr 23, 2020, 5:42:20 PM (5 years ago)

Author:

Tom Goddard

Comment:

--

RestAPI

@@ -1 +1 @@
 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 [attachment:"Remote interface discussion text.pdf" description] of his Phenix / ChimeraX communication API  to Phenix developers on October 1, 2019.  A [attachment:ChimeraXPhenix.docx​" more recent description] is in his Phenix/ChimeraX interaction write-up.
+Tristan sent a [attachment:"Remote interface discussion text.pdf" description] of his Phenix / ChimeraX communication API  to Phenix developers on October 1, 2019.  A [attachment:ChimeraXPhenix.docx​ more recent description] is in his Phenix/ChimeraX interaction write-up and duplicated below.
 
 His [https://github.com/tristanic/isolde/tree/master/isolde/src/remote_control REST implementation in ISOLDE] is part of the [https://github.com/tristanic/isolde ISOLDE Github repository].
 
-RBVI discussed whether his REST API should be included in the standard ChimeraX distribution in our [wiki:2019-08-29 August 29, 2019 developer meeting].
+RBVI discussed whether his REST API should be included in the standard ChimeraX distribution in our [wiki:2019-08-29 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).