Appropriate names for the Connectivity Insights paths

[Kevsy]

Currently the 0.3.0-wip API has network-monitoring in the operation request paths and I don't think that represents the intent.

'Network monitoring' seems like telco language , which is against the CAMARA guidelines. And this API does not monitor the network.

For network-monitoring/policy:
policy typically means a set of rules, whereas the consumer of this API is rather providing a set of thresholds, beyond which the end user will get poor experience. Policy seems more something the network would have, rather than something the consumer would provision to it.

Some more intent-based paths could be:
network-performance
network-quality
etc.

For policy some suggestions:
thresholds
tolerances
etc.

Any thoughts welcome!

[maheshc01]

alternate recommendations discussed during the call. 3/13

/network-performance/profile
/network-performance/app-profile
/network-performance/application-profile

/network-quality/profile
/network-quality/app-profile
/network-quality/application-profile

[Kevsy]

I think it will help to take into account the base path, /connectivity-insights/, as it has a clear meaning and helps guide the name of the remaining path elements/resources. I can think of two options:

Option 1

Based on /connectivity-insights/network-quality/:

POST /connectivity-insights/network-quality/application-profiles

• to declare the network quality thresholds for the application
• this creates a resource at /connectivity-insights/network-quality/application-profiles/{applicationProfileId} for GET|PUT|DELETE

POST /connectivity-insights/network-quality/insights

• to request insight of how the network believes a given device will experience a given applicationProfile under current network conditions
• this creates a resource at /connectivity-insights/network-quality/insights/{insightId} for GET | DELETE (not sure about PUT)

Notifications would follow /connectivity-insights//network-quality/insights/subscription

Option 2:

Based on /connectivity-insights/ . Here, network-quality is part of the resource model, but not in the path.

POST /connectivity-insights/application-profiles

• to declare the network quality thresholds for the application:
• this creates a resource at /connectivity-insights/application-profiles/{applicationProfileId} for GET|PUT|DELETE

POST /connectivity-insights/

• to request insight of how the network believes a given device will experience a given applicationProfile under current network conditions
• this creates a resource at /connectivity-insights/{insightId} for GET | DELETE (not sure about PUT)

Notifications would follow /connectivity-insights/subscriptions/{subscriptionId}

---

I like Option 2 as it seems neater and avoids 'path bloat'. WDYT?

[Kevsy]

Agreed in YAML as `check-network-quality' per API Design guidelines