Remove "endpoints" field from /network/<id>

[rlane]

Currently querying /network/<id> returns a list of all endpoints in the network. If all you want is the name of the network, then getting thousands of endpoints is an unnecessary cost. If a remote plugin queries the network name on each CreateEndpoint call then this makes the process of creating endpoints quadratic time.

Instead, there could be a /network/<id>/endpoints resource that returns the list.

edit: @aboch pointed out /network/<id>/endpoints already exists - thanks!

[aboch]

When doing a GET on a network resource, I feel the expected behavior is to get all the info about that resource.
Maybe here the real issue is there is no alternate (lighter) way to retrieve the net name from the net id.

If there isn't any elegant way to do this (get only one property of the network resource), we can go ahead and remove the endpoint resources from the network resource, given we already have the URL for endpoints under a network: '"/networks/" + nwID + "/endpoints"'

[rlane]

Oh, I didn't realize /networks/<id>/endpoints already existed. I updated the title (and fixed some markdown errors in the description).

[dave-tucker]

Typical way to do this is to allow pagination/sorting/filtering as a query string.

E,g /networks/<id>?limit=1 would return only one endpoint, so if you only want the ID of that network you can grab it there...

Thinking about this a little further, couldn't you use /networks?name=foo or /networks?id=aabbcc12345 which would provide only the network of interest from the networks resource.

[aboch]

@dave-tucker Issue here is not a missing API, but the efficiency of getting the nw name from the nw id in a scaled setup with the current API: GET networks/<id> given the returned resource description is also packed with all the nw's endpoints.

[aboch]

Finally looking into this, I think this would be taken care if we move to a more REST way, where a GET on a collection returns the list of members' identifiers, not the member themselves.

Same can be done for the network resource representation: the member endpoints should be represented sa a collection of endpoint ids. The full expansion of the endpoint will be achieved via the GET networks/<id>/endpoints/<id>

We should modify all existing URL endpoints to behave this way.

[rlane]

@aboch Would GET networks/<id> then return a list of endpoint IDs in the endpoints field, or would the endpoints field be removed?

[aboch]

@rlane I was thinking the endpoints field would not be removed, rather it would contain a list of endpoints id.

[dave-tucker]

@aboch how about we return the both the ID and name - which I think is required to keep the functionality of the current query strings we have. Then to answer @rlane's question, we can add an id query string so you can get the network's name as follows

GET /networks?id=aabbccdd12345789

e.g "get the networks resource and filter it to only show elements where the id is equal to aabbccdd12345789"

This would return:

[
  { 
    "id": "aabbccdd12345789",
    "name" : "foo"
  }
]

A GET to /networks would return just the name and ID of all known networks

[
  { 
    "id": "aabbccdd12345789",
    "name" : "foo"
  },
  { 
    "id": "aabbccdd12345799",
    "name" : "bar"
  }
]

/networks/<id> would provide the names and id's of all endpoints under the endpoint collection, and these can be further inspected in /networks/<id>/endpoints/<id>

[aboch]

@dave-tucker I think you are suggesting the GET from collection to return a list of resources in partial representation form.

I see other references to this approach on line and simply driven by practicality.
IIUC, it seems github REST API follow the same principle for large collections, they call it 'Summary Representations`.

Thanks for suggesting this, LGTM.

[GordonTheTurtle]

@rlane It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

• For a bug: do you still experience the issue with the latest version?
• For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to #1926