Moving away from reliance on Cytoscape selection

[dotasek]

I'm revisiting a review we did on CyREST vs. the Cytoscape API, and I noticed that there's an immense reliance on the Node/Edge selection.

The way that some workflows would have to work now is as follows:

1) Make a selection 2) Perform a task that uses the selection as a parameter (Zoom to selection, etc.)

or

1) Make a selection 2) Perform as task that alters the selection (Select neighbours, etc.) 3) Return the selection

I wonder if it would be of benefit to people making scripts if this reliance on selection was reduced; if CyREST let you pass nodes and edges as JSON directly to/from more endpoints.

For example, a zoom operation that just lets you send a list of nodes to include in the view, or a neighbours function that accepts a list of node SUIDs as a parameter and returns the neighbouring nodes as a list of SUIDs.

These would definitely be more RESTful, and, from a programmer's perspective, would reduce boilerplate code in the libraries. Thoughts?

[scootermorris]

That's essentially what we did with commands.  For the most part, anywhere a "nodeList" can be passed, you can either say "selected", provide a list of nodes, or a search to match (e.g. node type:protein).

-- scooter

On 03/20/2018 08:29 AM, dotasek wrote:

I'm revisiting a review we did on CyREST vs. the Cytoscape API, and I noticed that there's an immense reliance on the Node/Edge selection.

The way that some workflows would have to work now is as follows:

1. Make a selection
2. Perform a task that uses the selection as a parameter (Zoom to selection, etc.)

or

1. Make a selection
2. Perform as task that alters the selection (Select neighbours, etc.)
3. Return the selection

I wonder if it would be of benefit to people making scripts if this reliance on selection was reduced; if CyREST let you pass nodes and edges as JSON directly to/from more endpoints.

For example, a zoom operation that just lets you send a list of nodes to include in the view, or a neighbours function that accepts a list of node SUIDs as a parameter and returns the neighbouring nodes as a list of SUIDs.

These would definitely be more RESTful, and, from a programmer's perspective, would reduce boilerplate code in the libraries. Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cytoscape/cyREST/issues/73, or mute the thread https://github.com/notifications/unsubscribe-auth/AC80-FEIawQmzhuRacWqR7rIQZXGI9jPks5tgSBggaJpZM4SyHem.

[dotasek]

The nodeList in the best-case automation scenario is treated as a String that needs to be parsed and formatted within R or Python, with special-case values. I'm suggesting an approach that would more explicitly handle just arrays of SUIDs, so that they could be validated and streamed to/from Scripting languages more easily.

[dotasek]

Decoupling this issue from previous mentions in favour of a list of possible functions to be supported (this way, I can close #72 for example, and later make an issue for supporting Show/Hide for multiple objects).

• [ ] Cut / Copy / Paste
• [ ] Show / Hide Visual Properties

[dotasek]

Some general thinking-out-loud:

If we filter the level above from individual objects, we might get some useful functionality:

GET /v1/networks/{networkId}/views/{viewId}/{objectType}/ for example, is a level up from GET /v1/networks/{networkId}/views/{viewId}/{objectType}/{objectId}, and could be given this standard filter: /v1/networks/{networkId}/views/{viewId}/{objectType}?suid=1&suid=2&suid=3 or something similar (Ignore for a moment that HTTP will limit the length of this request, thereby making this terrible for use with large graphs).

The problem here is that to be RESTful, whatever I PUT should also be returned by the GET. If I PUT a fragment such as

 {
    "visualProperty": "NODE_VISIBLE",
    "value": false
  }

Then one would expect the entire content of the SUID's visual properties to be the passed data (not what we want to do).

This might be the domain of PATCH. Will have to inspect this.