Edges with multiple (and thus ambiguous) source/target keys

[scholer]

Hi, thanks for writing this great app for Cytoscape, I've enjoyed using it so far.
I ran into a weird issue when POSTing a network directly to /v1/networks/ - as shown in examples/python/basic/CytoscapeREST_Basic1.ipynb

The problem arises when creating a network "from the ground up", and the nodes/edges are created using names instead of SUIDs - as done in the example notebook. (Is it even possible to use SUIDs? - I assume SUIDs are assigned by Cytoscape and therefore can't be known in advance when building the graph data structure manually?).

Now, we specify edge 'source' and 'target' in the data structure as e.g. 'a' and 'b', and then POST the data structure to /v1/networks/. However, when we look at the network's data structure after creating it, we see something like:

  "data" : {
    "id" : "3285",
    "source" : "3259",
    "target" : "3258",
    "SUID" : 3285,
    "source" : "b",
    "selected" : false,
    "target" : "a"
  }

Notice how there is two "source" keys and two "target" keys! Obviously, this creates some ambiguity about which entry is the correct. - Is it the ones that has the assigned SUIDs, or is it the source/target with the original names? (RFC7159 recommends that object names SHOULD be unique.) If parsing the above with e.g. python, we will get the latter keys, e.g. "source" : "b", "target": "a", which is also what we get from e.g. /v1/networks//tables/defaultedge/ - however getting non-SUIDs as "source" and "target" seems inconsistent. Especially since when we are creating edges directly by POSTing to /v1/networks//edges, then we must give node SUIDs - POSTing [{'source': 'b', 'target': 'c'}] to the resource yields an error 500: Internal server error ("could not create edge" message).

Is it intended for cyREST to really have multiple "source" and "target" entries? It would seem to me there should only be one "source" and one "target", and that should be the node SUID (not name). If a new SUID is assigned to an edge (which, clearly, is the case above), and we wanted to save the original source/target values, those should be saved under a new key, e.g. "source-name"/"target-name" or something.

Code to replicate the issue: (based on the notebook example)

import requests, json, copy, string, webbrowser
# Basic Setup
PORT_NUMBER = 1234
BASE = 'http://localhost:' + str(PORT_NUMBER) + '/v1/'
HEADERS = {'Content-Type': 'application/json'}

empty_network = {'data': {'name': 'I\'m empty!'}, 'elements': {'nodes':[], 'edges':[]}}
small_network = copy.deepcopy(empty_network)

seq_letters = string.ascii_lowercase
abc_nodes = [{'data': { 'id': x }} for x in seq_letters]
rand_edges = [{'data': { 'source': x, 'target': 'a' }} for x in seq_letters]

small_network['elements']['nodes'] = abc_nodes
small_network['elements']['edges'] = rand_edges
small_network['data']['name'] = 'A is the hub.'

# Uncomment this if you want to see the actual JSON object
# print(json.dumps(small_network, indent=4))

res3 = requests.post(BASE + 'networks?collection=My%20Collection2', data=json.dumps(small_network), headers=HEADERS)
res3_dict = res3.json()
new_suid = res3_dict['networkSUID']
print("New network SUID:", new_suid)
webbrowser.open(BASE + 'networks/' + str(new_suid))
# Apply layout
requests.get(BASE + 'apply/layouts/force-directed/' + str(new_suid))

# Although the network data structure shown in the browser has "b" and "c" as edge "source" entries.
# However, using "b" and "c" to create a new edge won't work:
edges = [{'source': 'b', 'target': 'c'}]
res4 = requests.post("%snetworks/%s/" % (BASE, new_suid), data=json.dumps(edges), headers=HEADERS)
print(res4, res4.reason)