Just asking a question about the Network Link resource

[garethsb]

The Network Link resources at /network-links are unusual in NMOS APIs because they don't have their own unique ID, they can only be queried based on the peer identifiers.

(That also explains why there isn't an /network-links/{networkLinkId} resource in the API RAML).

They're also unusual in that they contain a reference attribute that may refer to two different resource types, the "device_id" may refer to either an Endpoint or a Network Device.

Though it is not backwards compatible, the following schema seems to be much more natural, and consistent with other NMOS APIs...

[garethsb]

Adding "link_type": "access" to Endpoint-Network Device links and "link_type": "trunk" to inter-Network Device links would make additional useful basic queries about the topology possible also.

/network-links?link_type=trunk /network-links?link_type=access&peers.device_id={networkDeviceId}

[garethsb]

During the group call today, we discussed whether there is actually a use-case to include the Endpoint-to-Network Device links (I called this link type "access" but "host" or "endpoint" may be better). One opinion was that only the otherwise invisible or opaque inter-switch links are useful. The "attached_network_device" info in the Endpoint basically defines those links already.

[garethsb]

Rebased on v1.0.x, with link_type enum values changed to "network-device" (inter-switch links) and "endpoint" (switch-host links).

Making the basic queries things like:

• /network-links?link_type=network-device
  (all inter-switch links)
• /network-links?link_type=network-device&peers.device_id={networkDeviceId}
  (all inter-switch links with the specified switch)
• /network-links?link_type=endpoint&peers.device_id={networkDeviceId}
  (all endpoint links with the specified switch)
• /network-links?link_type=endpoint&peers.endpoint_id={endpointId}
  (the link from the specified endpoint)

[garethsb]

Withdrawn for v1.0.x, in favour of #69.